Re: [PATCH] drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found
Hi Marek,
2024년 4월 25일 (목) 오후 6:49, Marek Szyprowski 님이 작성:
>
> When reading EDID fails and driver reports no modes available, the DRM
> core adds an artificial 1024x786 mode to the connector. Unfortunately
> some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not
> able to drive such mode, so report a safe 640x480 mode instead of nothing
> in case of the EDID reading failure.
>
> This fixes the following issue observed on Trats2 board since commit
> 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"):
Applied.
Thanks,
Inki Dae
>
> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping operations
> exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops)
> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
> exynos-dsi 11c8.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0
> device (lanes:4 bpp:24 mode-flags:0x10b)
> exynos-drm exynos-drm: bound 11c8.dsi (ops exynos_dsi_component_ops)
> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
> [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
> exynos-hdmi 12d0.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not
> reach steady state
> panel-samsung-s6e8aa0 11c8.dsi.0: ID: 0xa2, 0x20, 0x8c
> exynos-mixer 12c1.mixer: timeout waiting for VSYNC
> [ cut here ]
> WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682
> drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
> [CRTC:70:crtc-1] vblank wait timed out
> Modules linked in:
> CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913
> Hardware name: Samsung Exynos (Flattened Device Tree)
> Workqueue: events_unbound deferred_probe_work_func
> Call trace:
> unwind_backtrace from show_stack+0x10/0x14
> show_stack from dump_stack_lvl+0x68/0x88
> dump_stack_lvl from __warn+0x7c/0x1c4
> __warn from warn_slowpath_fmt+0x11c/0x1a8
> warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
> drm_atomic_helper_wait_for_vblanks.part.0 from
> drm_atomic_helper_commit_tail_rpm+0x7c/0x8c
> drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184
> commit_tail from drm_atomic_helper_commit+0x168/0x190
> drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0
> drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c
> drm_client_modeset_commit_atomic from
> drm_client_modeset_commit_locked+0x60/0x1cc
> drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40
> drm_client_modeset_commit from
> __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4
> __drm_fb_helper_restore_fbdev_mode_unlocked from
> drm_fb_helper_set_par+0x2c/0x3c
> drm_fb_helper_set_par from fbcon_init+0x3d8/0x550
> fbcon_init from visual_init+0xc0/0x108
> visual_init from do_bind_con_driver+0x1b8/0x3a4
> do_bind_con_driver from do_take_over_console+0x140/0x1ec
> do_take_over_console from do_fbcon_takeover+0x70/0xd0
> do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac
> fbcon_fb_registered from register_framebuffer+0x190/0x21c
> register_framebuffer from
> __drm_fb_helper_initial_config_and_unlock+0x350/0x574
> __drm_fb_helper_initial_config_and_unlock from
> exynos_drm_fbdev_client_hotplug+0x6c/0xb0
> exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94
> drm_client_register from exynos_drm_bind+0x160/0x190
> exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8
> try_to_bring_up_aggregate_device from __component_add+0xb0/0x170
> __component_add from mixer_probe+0x74/0xcc
> mixer_probe from platform_probe+0x5c/0xb8
> platform_probe from really_probe+0xe0/0x3d8
> really_probe from __driver_probe_device+0x9c/0x1e4
> __driver_probe_device from driver_probe_device+0x30/0xc0
> driver_probe_device from __device_attach_driver+0xa8/0x120
> __device_attach_driver from bus_for_each_drv+0x80/0xcc
> bus_for_each_drv from __device_attach+0xac/0x1fc
> __device_attach from bus_probe_device+0x8c/0x90
> bus_probe_device from deferred_probe_work_func+0x98/0xe0
> deferred_probe_work_func from process_one_work+0x240/0x6d0
> process_one_work from worker_thread+0x1a0/0x3f4
> worker_thread from kthread+0x104/0x138
> kthread from ret_from_fork+0x14/0x28
> Exception stack(0xf0895fb0 to 0xf0895ff8)
> ...
> irq event stamp: 82357
> hardirqs last enabled at (82363): [] vprintk_emit+0x308/0x33c
> hardirqs last disabled at (82368): [] vprintk_emit+0x2bc/0x33c
> softirqs last enabled at (81614): [] __do_softirq+0x320/0x500
> softirqs last disabled at (81609): [] __irq_exit_rcu+0x130/0x184
> ---[ end trace ]---
> exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
&g
Re: [PATCH] gpu: drm: exynos: hdmi: eliminate uses of of_node_put()
Good cleanup. Applied. :)
Thanks,
Inki Dae
2024년 4월 15일 (월) 오전 9:40, Shivani Gupta 님이 작성:
>
> Utilize the __free() cleanup handler within the hdmi_get_phy_io function
> to automatically release the device node when it is out of scope.
> This eliminates the manual invocation of of_node_put(), reducing the
> potential for memory leaks.
>
> The modification requires initializing the device node at the beginning
> of the function, ensuring that the automatic cleanup is safely executed.
>
> Consequently, this removes the need for error cleanup paths that utilize
> goto statements and the jump to out is no longer necessary.
>
> Suggested-by: Julia Lawall
> Signed-off-by: Shivani Gupta
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index b1d02dec3774..a741fd949482 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1919,10 +1919,9 @@ static int hdmi_get_ddc_adapter(struct hdmi_context
> *hdata)
> static int hdmi_get_phy_io(struct hdmi_context *hdata)
> {
> const char *compatible_str = "samsung,exynos4212-hdmiphy";
> - struct device_node *np;
> - int ret = 0;
> + struct device_node *np __free(device_node) =
> + of_find_compatible_node(NULL, NULL, compatible_str);
>
> - np = of_find_compatible_node(NULL, NULL, compatible_str);
> if (!np) {
> np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
> if (!np) {
> @@ -1937,21 +1936,17 @@ static int hdmi_get_phy_io(struct hdmi_context *hdata)
> if (!hdata->regs_hdmiphy) {
> DRM_DEV_ERROR(hdata->dev,
> "failed to ioremap hdmi phy\n");
> - ret = -ENOMEM;
> - goto out;
> + return -ENOMEM;
> }
> } else {
> hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
> if (!hdata->hdmiphy_port) {
> DRM_INFO("Failed to get hdmi phy i2c client\n");
> - ret = -EPROBE_DEFER;
> - goto out;
> + return -EPROBE_DEFER;
> }
> }
>
> -out:
> - of_node_put(np);
> - return ret;
> + return 0;
> }
>
> static int hdmi_probe(struct platform_device *pdev)
> --
> 2.34.1
>
>
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just two cleanups - one is remove the .owner field from the platform_driver declarations in Exynos DRM modules and other is to drop the device_node cleanup code in exynos_hdmi.c using the scope-based resource management. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 83221064c28a0f9fdc4f63ab4fce2e51bfe23315: Merge tag 'drm-xe-next-2024-04-23' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next (2024-04-24 10:51:29 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-6.10 for you to fetch changes up to d65bfb9546eb627e3c578336355c5b81797f2255: gpu: drm: exynos: hdmi: eliminate uses of of_node_put() (2024-04-25 09:37:12 +0900) Two cleanups - Drop .owner from platform_driver declaration of each exynos drm module. - Drop the cleanup code to device_node object in exynos_hdmi.c using the scope-based resource management feature[1]. [1] https://lwn.net/Articles/934679/?ref=upstract.com Krzysztof Kozlowski (11): drm/exynos: fimc: drop driver owner initialization drm/exynos: fimd: drop driver owner initialization drm/exynos: dsi: drop driver owner initialization drm/exynos: g2d: drop driver owner initialization drm/exynos: gsc: drop driver owner initialization drm/exynos: mic: drop driver owner initialization drm/exynos: rotator: drop driver owner initialization drm/exynos: scaler: drop driver owner initialization drm/exynos: vidi: drop driver owner initialization drm/exynos: hdmi: drop driver owner initialization drm/exynos: mixer: drop driver owner initialization Shivani Gupta (1): gpu: drm: exynos: hdmi: eliminate uses of of_node_put() drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 - drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 - drivers/gpu/drm/exynos/exynos_drm_fimd.c| 1 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 - drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 - drivers/gpu/drm/exynos/exynos_drm_mic.c | 1 - drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 - drivers/gpu/drm/exynos/exynos_drm_scaler.c | 1 - drivers/gpu/drm/exynos/exynos_drm_vidi.c| 1 - drivers/gpu/drm/exynos/exynos_hdmi.c| 16 +--- drivers/gpu/drm/exynos/exynos_mixer.c | 1 - 11 files changed, 5 insertions(+), 21 deletions(-)
[GIT PULL] drm-misc-fixes
Hi Dave and Daniel, Just one regression fixup to samsung-dsim.c module. I attempted a pull request on the drm-misc tree but encountered a permission issue. In response to this, I've created an issue[1] on gitlab.freedesktop.org. Therefore, I added the drm-misc tree as a remote to the drm-exynos tree. This pull request is based on the latest drm-misc-fixes branch of the drm-misc tree. Please kindly let me know if there is any problem. Thanks, Inki Dae [1] https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/1151 The following changes since commit 27d19268cf394f2c78db732be0cb31852eeadb0a: accel/ivpu: Improve recovery and reset support (2024-01-25 10:17:37 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/drm-misc-fixes-for-v6.8-rc2 for you to fetch changes up to ff3d5d04db07e5374758baa7e877fde8d683ebab: drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE (2024-01-26 22:48:47 +0900) One regression fixup to samsung-dsim.c module - The FORCE_STOP_STATE bit is ineffective for forcing DSI link into LP-11 mode, causing timing issues and potential bridge failures. This patch reverts previous commits and corrects this issue. Michael Walle (1): drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE drivers/gpu/drm/bridge/samsung-dsim.c | 32 ++-- 1 file changed, 2 insertions(+), 30 deletions(-)
Inquiry regarding the use of the dim tool
Dear all,
I'm attempting to make a pull request to the drm-misc tree -
drm-misc-fixes branch - but am encountering an issue as follows:
daeinki@daeinki-virtual-machine:~/project/mainline$ GIT_CURL_VERBOSE=1
GIT_TRACE=1 ./dim push-branch drm-misc-fixes
15:53:53.966461 git.c:344 trace: built-in: git version
15:53:53.975543 git.c:344 trace: built-in: git
symbolic-ref -q --short HEAD
15:53:53.985852 git.c:344 trace: built-in: git remote -v
15:53:53.990337 git.c:344 trace: built-in: git remote -v
15:53:53.994804 git.c:344 trace: built-in: git remote -v
15:53:54.001999 git.c:344 trace: built-in: git config
--get user.email
15:53:54.005279 git.c:344 trace: built-in: git rev-list
'drm-misc-fixes@{u}..drm-misc-fixes' --first-parent
--committer=inki@samsung.com --no-merges
15:53:54.011711 git.c:344 trace: built-in: git log -1
437eea2a59f193be9dee439b1f483b8f8e44e56f '--pretty=format:%H ("%s")%n'
15:53:54.015629 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f '--format=format:%an'
15:53:54.019062 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f '--format=format:%ae'
15:53:54.023306 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f '--format=format:%cn'
15:53:54.028380 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f '--format=format:%an'
15:53:54.034737 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f '--format=format:%ae %ce'
15:53:54.039538 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.042555 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.044988 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.048174 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.051992 git.c:344 trace: built-in: git show -s
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.056200 git.c:344 trace: built-in: git log -1
'--format=%B' 437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.058814 git.c:344 trace: built-in: git log -1
437eea2a59f193be9dee439b1f483b8f8e44e56f '--pretty=format:%H ("%s")%n'
15:53:54.062107 git.c:344 trace: built-in: git rev-parse
--verify -q 20c827683de0
15:53:54.063871 git.c:344 trace: built-in: git
merge-base --is-ancestor 20c827683de0
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:54.609416 git.c:344 trace: built-in: git show -s
20c827683de0 '--format=format:%s'
15:53:54.612067 git.c:344 trace: built-in: git rev-parse
--verify -q 0c14d3130654
15:53:54.613680 git.c:344 trace: built-in: git
merge-base --is-ancestor 0c14d3130654
437eea2a59f193be9dee439b1f483b8f8e44e56f
15:53:55.665041 git.c:344 trace: built-in: git show -s
0c14d3130654 '--format=format:%s'
15:53:55.669444 git.c:344 trace: built-in: git rev-list
'drm-misc-fixes@{u}..drm-misc-fixes' --first-parent
--committer=inki@samsung.com --merges
15:53:55.672323 git.c:344 trace: built-in: git rev-list
--count --no-merges --first-parent
'drm-misc-fixes@{u}..drm-misc-fixes'
15:53:55.674971 git.c:344 trace: built-in: git rev-list
--count --merges --first-parent 'drm-misc-fixes@{u}..drm-misc-fixes'
15:53:55.677152 git.c:344 trace: built-in: git push
--push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually
origin drm-misc-fixes
fatal: remote error: access denied or repository not exported: /drm/drm-misc
I've already obtained the commit rights[1] to drm-misc. Following the
guide[2], I've completed all the necessary setup. However, I'm running
into a problem where the command `dim push-branch drm-misc-fixes`
doesn't seem to work after I merge a patch using the command `cat
1.mbox | dim apply-branch drm-misc-fixes`.
[1] https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/569
[2] https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
I'm still not quite familiar with using the dim tool. I'm sure there
must be some aspects I'm missing. Could I please get some help with
this?
Thanks,
Inki Dae
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just several fixups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 0dd3ee31125508cd67f7e7172247f05b7fd1753a: Linux 6.7 (2024-01-07 12:18:38 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.8-rc2 for you to fetch changes up to 4050957c7c2c14aa795dbf423b4180d5ac04e113: drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume (2024-01-22 12:24:55 +0900) Several fixups - Minor fix in `drm/exynos: gsc: gsc_runtime_resume` . The patch ensures `clk_disable_unprepare()` is called on the first element of `ctx->clocks` array. This issue was identified by the Linux Verification Center. - Fix excessive stack usage in `fimd_win_set_pixfmt()` in `drm/exynos` . The issue, highlighted by gcc, involved an unnecessary on-stack copy of the large `exynos_drm_plane` structure, now replaced with a pointer. - Fix an incorrect type issue in `exynos_drm_fimd.c` module . Addresses an incorrect type issue in `fimd_commit()` within the `exynos_drm_fimd.c` The problem was reported by the kernel test robot[1]. [1] https://lore.kernel.org/oe-kbuild-all/202312140930.me9ywf8f-...@intel.com/ - Fix a typo in the dt-bindings for `samsung,exynos-mixer` . Changes 'regs' to the correct property name 'reg' in the dt-bindings documentation for `samsung,exynos-mixer` Arnd Bergmann (1): drm/exynos: fix accidental on-stack copy of exynos_drm_plane Fedor Pchelkin (1): drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume Inki Dae (1): drm/exynos: fix incorrect type issue Rob Herring (1): dt-bindings: display: samsung,exynos-mixer: Fix 'regs' typo .../devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml | 6 +++--- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++-- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 6 +++--- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-)
Re: [PATCH] drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE
Really sorry for late. Will pick it up. Thanks, Inki Dae 2024년 1월 9일 (화) 오후 9:50, Daniel Vetter 님이 작성: > On Tue, Jan 09, 2024 at 09:47:20AM +0100, Michael Walle wrote: > > Hi, > > > > > > Inki, are you picking this up? Or if not, who will? > > > > > > I can pick it up but it would be better to go to the drm-misc tree. If > > > nobody cares about it then I will pick it up. :) > > > > > > acked-by : Inki Dae > > > > Who is going to pick this up? Who has access to the drm-misc tree? > > Inki has, so I'm assuming since he acked he'll also merge. > -Sima > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >
Re: [PATCH] drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume
2023년 12월 20일 (수) 오후 7:45, Marek Szyprowski 님이 작성:
> On 20.12.2023 10:53, Fedor Pchelkin wrote:
> > Do not forget to call clk_disable_unprepare() on the first element of
> > ctx->clocks array.
> >
> > Found by Linux Verification Center (linuxtesting.org).
> >
> > Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core
> API")
> > Signed-off-by: Fedor Pchelkin
> Reviewed-by: Marek Szyprowski
>
Applied.
Thanks,
Inki Dae
> ---
> > 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.c
> > index 34cdabc30b4f..5302bebbe38c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> > @@ -1342,7 +1342,7 @@ static int __maybe_unused
> gsc_runtime_resume(struct device *dev)
> > for (i = 0; i < ctx->num_clocks; i++) {
> > ret = clk_prepare_enable(ctx->clocks[i]);
> > if (ret) {
> > - while (--i > 0)
> > + while (--i >= 0)
> > clk_disable_unprepare(ctx->clocks[i]);
> > return ret;
> > }
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
>
Re: [PATCH] drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE
2023년 12월 19일 (화) 오전 11:11, Frieder Schrempf 님이
작성:
> On 01.12.23 10:04, Michael Walle wrote:
> >> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
> >> mode. It seems the bridge internally queues DSI packets and when the
> >> FORCE_STOP_STATE bit is cleared, they are sent in close succession
> >> without any useful timing (this also means that the DSI lanes won't go
> >> into LP-11 mode). The length of this gibberish varies between 1ms and
> >> 5ms. This sometimes breaks an attached bridge (TI SN65DSI84 in this
> >> case). In our case, the bridge will fail in about 1 per 500 reboots.
> >>
> >> The FORCE_STOP_STATE handling was introduced to have the DSI lanes in
> >> LP-11 state during the .pre_enable phase. But as it turns out, none of
> >> this is needed at all. Between samsung_dsim_init() and
> >> samsung_dsim_set_display_enable() the lanes are already in LP-11 mode.
> >> The code as it was before commit 20c827683de0 ("drm: bridge:
> >> samsung-dsim: Fix init during host transfer") and 0c14d3130654 ("drm:
> >> bridge: samsung-dsim: Fix i.MX8M enable flow to meet spec") was correct
> >> in this regard.
> >>
> >> This patch basically reverts both commits. It was tested on an i.MX8M
> >> SoC with an SN65DSI84 bridge. The signals were probed and the DSI
> >> packets were decoded during initialization and link start-up. After this
> >> patch the first DSI packet on the link is a VSYNC packet and the timing
> >> is correct.
> >>
> >> Command mode between .pre_enable and .enable was also briefly tested by
> >> a quick hack. There was no DSI link partner which would have responded,
> >> but it was made sure the DSI packet was send on the link. As a side
> >> note, the command mode seems to just work in HS mode. I couldn't find
> >> that the bridge will handle commands in LP mode.
> >>
> >> Fixes: 20c827683de0 ("drm: bridge: samsung-dsim: Fix init during host
> >> transfer")
> >> Fixes: 0c14d3130654 ("drm: bridge: samsung-dsim: Fix i.MX8M enable
> >> flow to meet spec")
> >> Signed-off-by: Michael Walle
> >> ---
> >> Let me know wether this should be two commits each reverting one, but
> >> both
> >> commits appeared first in kernel 6.5.
> >
> > Are there any news?
>
> Inki, are you picking this up? Or if not, who will?
>
I can pick it up but it would be better to go to the drm-misc tree. If
nobody cares about it then I will pick it up. :)
acked-by : Inki Dae
Thanks,
Inki Dae
Re: [PATCH] drm/exynos: fix accidental on-stack copy of exynos_drm_plane
2023년 12월 15일 (금) 오전 12:59, Marek Szyprowski 님이
작성:
> On 14.12.2023 13:32, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > gcc rightfully complains about excessive stack usage in the
> fimd_win_set_pixfmt()
> > function:
> >
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c: In function
> 'fimd_win_set_pixfmt':
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c:750:1: error: the frame size of
> 1032 bytes is larger than 1024 byte
> > drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function
> 'decon_win_set_pixfmt':
> > drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:1: error: the frame
> size of 1032 bytes 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")
> > Signed-off-by: Arnd Bergmann
>
>
> Reviewed-by: Marek Szyprowski
>
Thanks,
Inki Dae
>
>
> > ---
> > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > index 4d986077738b..bce027552474 100644
> > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > @@ -319,9 +319,9 @@ static void decon_win_set_bldmod(struct
> decon_context *ctx, unsigned int win,
> > static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned
> int win,
> >struct drm_framebuffer *fb)
> > {
> > - struct exynos_drm_plane plane = ctx->planes[win];
> > + struct exynos_drm_plane *plane = >planes[win];
> > struct exynos_drm_plane_state *state =
> > - to_exynos_plane_state(plane.base.state);
> > + to_exynos_plane_state(plane->base.state);
> > unsigned int alpha = state->base.alpha;
> > unsigned int pixel_alpha;
> > unsigned long val;
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 8dde7b1e9b35..5bdc246f5fad 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -661,9 +661,9 @@ static void fimd_win_set_bldmod(struct fimd_context
> *ctx, unsigned int win,
> > static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int
> win,
> > struct drm_framebuffer *fb, int width)
> > {
> > - struct exynos_drm_plane plane = ctx->planes[win];
> > + struct exynos_drm_plane *plane = >planes[win];
> > struct exynos_drm_plane_state *state =
> > - to_exynos_plane_state(plane.base.state);
> > + to_exynos_plane_state(plane->base.state);
> > uint32_t pixel_format = fb->format->format;
> > unsigned int alpha = state->base.alpha;
> > u32 val = WINCONx_ENWIN;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
>
[PATCH] drm/exynos: fix incorrect type issue
Fix incorrect type issue in fimd_commit() of exynos_drm_fimd.c module. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312140930.me9ywf8f-...@intel.com/ Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index a9f1c5c05894..60d1ef4010bb 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -480,7 +480,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc) struct fimd_context *ctx = crtc->ctx; struct drm_display_mode *mode = >base.state->adjusted_mode; const struct fimd_driver_data *driver_data = ctx->driver_data; - void *timing_base = ctx->regs + driver_data->timing_base; + void __iomem *timing_base = ctx->regs + driver_data->timing_base; u32 val; if (ctx->suspended) -- 2.25.1
Re: [PATCH] dt-bindings: display: samsung, exynos-mixer: Fix 'regs' typo
2023년 12월 14일 (목) 오전 7:43, Rob Herring 님이 작성:
> The correct property name is 'reg' not 'regs'.
>
Thanks,
Inki Dae
> Fixes: 68e89bb36d58 ("dt-bindings: display: samsung,exynos-mixer: convert
> to dtschema")
> Signed-off-by: Rob Herring
> ---
> .../bindings/display/samsung/samsung,exynos-mixer.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
> b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
> index 25d53fde92e1..597c9cc6a312 100644
> ---
> a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
> +++
> b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
> @@ -85,7 +85,7 @@ allOf:
> clocks:
>minItems: 6
>maxItems: 6
> -regs:
> +reg:
>minItems: 2
>maxItems: 2
>
> @@ -99,7 +99,7 @@ allOf:
> clocks:
>minItems: 4
>maxItems: 4
> -regs:
> +reg:
>minItems: 2
>maxItems: 2
>
> @@ -116,7 +116,7 @@ allOf:
> clocks:
>minItems: 3
>maxItems: 3
> -regs:
> +reg:
>minItems: 1
>maxItems: 1
>
> --
> 2.43.0
>
>
>
Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove callback returning void
Hello Uwe Kleine-König, 2023년 12월 7일 (목) 오후 5:03, Uwe Kleine-König 님이 작성: > > Hello Inki, > > On Thu, Dec 07, 2023 at 11:37:44AM +0900, 대인기/Tizen Platform Lab(SR)/삼성전자 > wrote: > > Hello Uwe Kleine-König, > > > > > -Original Message- > > > From: Uwe Kleine-König > > > Sent: Wednesday, November 29, 2023 1:55 AM > > > To: Inki Dae > > > Cc: linux-samsung-...@vger.kernel.org; Daniel Vetter ; > > > Jingoo Han ; Seung-Woo Kim ; > > > Kyungmin Park ; DRI mailing list > > de...@lists.freedesktop.org>; Krzysztof Kozlowski > > > ; ker...@pengutronix.de; Alim Akhtar > > > ; David Airlie ; linux-arm- > > > ker...@lists.infradead.org > > > Subject: Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove > > > callback returning void > > > > > > Hello Inki, > > > > > > On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-König wrote: > > > > Hello Inki, > > > > > > > > On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote: > > > > > Sorry for late. There was a merge conflict so I fixed it manually and > > > > > merged. And seems your patch description is duplicated so dropped > > > > > duplicated one. > > > > > > > > Ah. I have a template that generates one patch per driver. I guess this > > > > is the result of using squash instead of fixup while putting all exynos > > > > changes into a single patch. > > > > > > This patch didn't make it into next yet even though it's included in > > > your exynos-drm-next branch at > > > https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git. > > > > > > Is this on purpose? > > > > drm-exynos tree is not included in the next tree. It was previously > > included, but it has been removed. drm-exynos tree is merged into the > > mainline through the drm-next tree, but when the drm-next is > > synchronized to the next tree, a conflict occurred between the > > exynos-drm tree and the drm-next tree. Therefore, I had requested that > > drm-exynos tree be removed from the next. Perhaps I was inexperienced > > in managing the git tree at that time. :) > > That sounds more like a reason to have your tree in next. One of the > core motivations of next is to find inter-tree conflicts early. If such > a conflict occurs and you only notice it when it's time to send your PR > to drm-next (or even later) the pressure to fix the problem is higher. > > Also for patch contributors it's nice to have a "complete" next, their > tests are more expressive then. > > So I want to encourage you to readd your tree to next. Thanks for your feedback. Requested to Stephen Rothwell. :) Thanks, Inki Dae > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ |
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one fixup to shutdown relevant issue and two cleanups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit a2f8994c1001cfa48483a3afa3550016a3ab0a3e: Merge tag 'exynos-drm-next-for-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next (2023-12-12 13:06:29 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.8 for you to fetch changes up to ead5a41c8f8a13ad7b1c9fd2d7edb1ea909b777f: drm/exynos: dpi: Change connector type to DPI (2023-12-12 13:06:38 +0900) One bug fix - Add a missing call to drm_atomic_helper_shutdown() in Exynos DRM driver. This function is necessary during system shutdown and when the driver is unbound. Without this function, components like panels may not shut down properly, potentially leading to power issue as mentioned in the kernel documentation, specially in the "driver instance overview" secstion of 'drm_drv.c'. Two cleanups - Convert '.remove()' callback function in the Exynos DRM platform driver to a version that returns void instead of an integer. - Change connector type of exynos_drm_dpi.c module to DPI. Douglas Anderson (1): drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time Paul Cercueil (1): drm/exynos: dpi: Change connector type to DPI Uwe Kleine-König (1): drm/exynos: Convert to platform remove callback returning void drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++ drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 ++ drivers/gpu/drm/exynos/exynos_dp.c| 6 ++ drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +--- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 ++ drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++ 15 files changed, 40 insertions(+), 56 deletions(-)
[GIT PULL RESEND] exynos-drm-fixes
Hi Dave and Daniel, Just resending you the previous pull request[1] after resolving the build warning. [1] https://lore.kernel.org/dri-devel/20231120225537.1270358-1-inki@samsung.com/ Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 33924328498e903bea74727353e5012d29653aff: Merge tag 'drm-intel-fixes-2023-12-01-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2023-12-05 12:19:22 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.7-rc5 for you to fetch changes up to 8d1b7809684c688005706125b804e1f9792d2b1b: drm/exynos: fix a wrong error checking (2023-12-07 11:51:43 +0900) Two fixups - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported by Dan[1] [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/ Inki Dae (1): drm/exynos: fix a wrong error checking Xiang Yang (1): drm/exynos: fix a potential error pointer dereference drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++- drivers/gpu/drm/exynos/exynos_hdmi.c| 2 ++ 2 files changed, 5 insertions(+), 5 deletions(-)
[PATCH v2] drm/exynos: fix a wrong error checking
Fix a wrong error checking in exynos_drm_dma.c module.
In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.
However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.
This issue[1] was reported by Dan.
Changelog v1:
- fix build warning.
[1]
https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
Reported-by : Dan Carpenter
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c
b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index a971590b8132..e2c7373f20c6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -107,18 +107,16 @@ int exynos_drm_register_dma(struct drm_device *drm,
struct device *dev,
return 0;
if (!priv->mapping) {
- void *mapping;
+ void *mapping = NULL;
if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
mapping = arm_iommu_create_mapping(_bus_type,
EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
else if (IS_ENABLED(CONFIG_IOMMU_DMA))
mapping = iommu_get_domain_for_dev(priv->dma_dev);
- else
- mapping = ERR_PTR(-ENODEV);
- if (IS_ERR(mapping))
- return PTR_ERR(mapping);
+ if (!mapping)
+ return -ENODEV;
priv->mapping = mapping;
}
--
2.25.1
Re: [GIT PULL] exynos-drm-fixes
Hi Dave, 2023년 11월 24일 (금) 오전 10:14, Dave Airlie 님이 작성: > On Tue, 21 Nov 2023 at 09:00, Inki Dae wrote: > > > > Hi Dave and Daniel, > > > >Two fixups - fixing a potential error pointer dereference and wrong > >error checking. > Hi Inki, > > This fails to build on arm32, and it seems one of the fixes is wrong > > [airlied@dreadlord drm-fixes]$ make ARCH=arm > CROSS_COMPILE=arm-linux-gnu- O=../../arm-build-fixes/ -j16 > make[1]: Entering directory '/home/airlied/devel/kernel/arm-build-fixes' > GEN Makefile > CALL > /home/airlied/devel/kernel/dim/drm-fixes/scripts/checksyscalls.sh > CC [M] drivers/gpu/drm/exynos/exynos_drm_dma.o > > /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c: > In function ‘exynos_drm_register_dma’: > > /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c:119:40: > error: passing argument 1 of ‘PTR_ERR’ makes pointer from integer > without a cast [-Werror=int-conversion] > 119 | return PTR_ERR(-ENODEV); > In file included from > /home/airlied/devel/kernel/dim/drm-fixes/include/linux/string.h:9, > from > /home/airlied/devel/kernel/dim/drm-fixes/include/linux/dma-mapping.h:7, > from > /home/airlied/devel/kernel/dim/drm-fixes/include/linux/dma-map-ops.h:9, > from > > /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c:7: > /home/airlied/devel/kernel/dim/drm-fixes/include/linux/err.h:49:61: > note: expected ‘const void *’ but argument is of type ‘int’ >49 | static inline long __must_check PTR_ERR(__force const void *ptr) > | ^~~ > cc1: all warnings being treated as errors > > I think it should just be return -ENODEV, since the function returns an > int. > > Please fix it up and resend. > Really sorry for this. Will resend after fixing it. Thanks, Inki Dae > Thanks, > Dave. > > > > > > >Ps. regarding the first patch, I had sent a GIT-PULL[1] but it seems > >you missed. > >[1] > https://lore.kernel.org/dri-devel/20231006040950.4397-1-inki@samsung.com/T/#u > > > >Please kindly let me know if there is any problem. > > > > Thanks, > > Inki Dae > > > > The following changes since commit > 98b1cc82c4affc16f5598d4fa14b1858671b2263: > > > > Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > tags/exynos-drm-fixes-for-v6.7-rc3 > > > > for you to fetch changes up to a30ba4bd7cdb5726d86a557c5df8df71c7bc7fad: > > > > drm/exynos: fix a wrong error checking (2023-11-21 07:41:11 +0900) > > > > > > Two fixups > > - Fix a potential error pointer dereference by checking the return value > > of exynos_drm_crtc_get_by_type() function before accessing to crtc > > object. > > - Fix a wrong error checking in exynos_drm_dma.c modules, which was > reported > > by Dan[1] > > > > [1] > https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/ > > > > > > Inki Dae (1): > > drm/exynos: fix a wrong error checking > > > > Xiang Yang (1): > > drm/exynos: fix a potential error pointer dereference > > > > drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++- > > drivers/gpu/drm/exynos/exynos_hdmi.c| 2 ++ > > 2 files changed, 5 insertions(+), 5 deletions(-) > >
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Two fixups - fixing a potential error pointer dereference and wrong error checking. Ps. regarding the first patch, I had sent a GIT-PULL[1] but it seems you missed. [1] https://lore.kernel.org/dri-devel/20231006040950.4397-1-inki@samsung.com/T/#u Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.7-rc3 for you to fetch changes up to a30ba4bd7cdb5726d86a557c5df8df71c7bc7fad: drm/exynos: fix a wrong error checking (2023-11-21 07:41:11 +0900) Two fixups - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported by Dan[1] [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/ Inki Dae (1): drm/exynos: fix a wrong error checking Xiang Yang (1): drm/exynos: fix a potential error pointer dereference drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++- drivers/gpu/drm/exynos/exynos_hdmi.c| 2 ++ 2 files changed, 5 insertions(+), 5 deletions(-)
Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove callback returning void
Hi,
Sorry for late. There was a merge conflict so I fixed it manually and
merged. And seems your patch description is duplicated so dropped
duplicated one.
Thanks,
Inki Dae
2023년 11월 3일 (금) 오전 1:57, Uwe Kleine-König 님이
작성:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert the exynos drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
>
> drivers/gpu/drm/exynos/exynos_mixer.c :: Convert to platform remove
> callback returning void
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 ++
> drivers/gpu/drm/exynos/exynos_dp.c| 6 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 ++
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++
> 14 files changed, 28 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 4d986077738b..776f2f0b602d 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> -static int exynos5433_decon_remove(struct platform_device *pdev)
> +static void exynos5433_decon_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(>dev);
>
> component_del(>dev, _component_ops);
> -
> - return 0;
> }
>
> struct platform_driver exynos5433_decon_driver = {
> .probe = exynos5433_decon_probe,
> - .remove = exynos5433_decon_remove,
> + .remove_new = exynos5433_decon_remove,
> .driver = {
> .name = "exynos5433-decon",
> .pm = pm_ptr(_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0156a5e94435..0d185c0564b9 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -765,7 +765,7 @@ static int decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int decon_remove(struct platform_device *pdev)
> +static void decon_remove(struct platform_device *pdev)
> {
> struct decon_context *ctx = dev_get_drvdata(>dev);
>
> @@ -774,8 +774,6 @@ static int decon_remove(struct platform_device *pdev)
> iounmap(ctx->regs);
>
> component_del(>dev, _component_ops);
> -
> - return 0;
> }
>
> static int exynos7_decon_suspend(struct device *dev)
> @@ -840,7 +838,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops,
> exynos7_decon_suspend,
>
> struct platform_driver decon_driver = {
> .probe = decon_probe,
> - .remove
[PATCH] drm/exynos: fix a wrong error checking
Fix a wrong error checking in exynos_drm_dma.c module.
In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.
However, the error checking is performed using the statement
if(IS_ERR(mapping)),
which doesn't provide a suitable error value. So check if 'mapping' is NULL,
and if it is, return ERR_PTR(-ENODEV).
This issue[1] was reported by Dan.
[1] https://www.spinics.net/lists/dri-devel/msg418271.html
Reported-by : Dan Carpenter
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c
b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index a971590b81323..6d73d4dca583e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -107,18 +107,16 @@ int exynos_drm_register_dma(struct drm_device *drm,
struct device *dev,
return 0;
if (!priv->mapping) {
- void *mapping;
+ void *mapping = NULL;
if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
mapping = arm_iommu_create_mapping(_bus_type,
EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
else if (IS_ENABLED(CONFIG_IOMMU_DMA))
mapping = iommu_get_domain_for_dev(priv->dma_dev);
- else
- mapping = ERR_PTR(-ENODEV);
- if (IS_ERR(mapping))
- return PTR_ERR(mapping);
+ if (!mapping)
+ return PTR_ERR(-ENODEV);
priv->mapping = mapping;
}
--
2.17.1
Re: [RFT PATCH v2 09/12] drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time
Hi,
2023년 10월 6일 (금) 오후 10:51, Doug Anderson 님이 작성:
>
> Hi,
>
> On Thu, Oct 5, 2023 at 7:20 PM Inki Dae wrote:
> >
> > Thanks for testing. :)
> >
> > Acked-by : Inki Dae
>
> Inki: does that mean you'd like this to go through drm-misc? I'm happy
> to do that, but there are no dependencies here so this could easily go
> through your tree.
Ah, you are right. No dependency here. I will pick it up.
Thanks,
Inki Dae
>
>
> > 2023년 9월 22일 (금) 오후 3:00, Marek Szyprowski 님이 작성:
> > >
> > >
> > > On 21.09.2023 21:26, Douglas Anderson wrote:
> > > > Based on grepping through the source code this driver appears to be
> > > > missing a call to drm_atomic_helper_shutdown() at system shutdown time
> > > > and at driver unbind time. Among other things, this means that if a
> > > > panel is in use that it won't be cleanly powered off at system
> > > > shutdown time.
> > > >
> > > > The fact that we should call drm_atomic_helper_shutdown() in the case
> > > > of OS shutdown/restart and at driver remove (or unbind) time comes
> > > > straight out of the kernel doc "driver instance overview" in
> > > > drm_drv.c.
> > > >
> > > > A few notes about this fix:
> > > > - When adding drm_atomic_helper_shutdown() to the unbind path, I added
> > > >it after drm_kms_helper_poll_fini() since that's when other drivers
> > > >seemed to have it.
> > > > - Technically with a previous patch, ("drm/atomic-helper:
> > > >drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
> > > >actually need to check to see if our "drm" pointer is NULL before
> > > >calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
> > > >though, so that this patch can land without 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 Ripard
> > > > Signed-off-by: Douglas Anderson
> > >
> > > Seems to be working fine on all my test Exynos-based boards with display.
> > >
> > > Tested-by: Marek Szyprowski
> > >
> > > Reviewed-by: Marek Szyprowski
> > >
> > > > ---
> > > > This commit is only compile-time tested.
> > > >
> > > > (no changes since v1)
> > > >
> > > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++
> > > > 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > index 8399256cb5c9..5380fb6c55ae 100644
> > > > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > @@ -300,6 +300,7 @@ static int exynos_drm_bind(struct device *dev)
> > > > drm_mode_config_cleanup(drm);
> > > > exynos_drm_cleanup_dma(drm);
> > > > kfree(private);
> > > > + dev_set_drvdata(dev, NULL);
> > > > err_free_drm:
> > > > drm_dev_put(drm);
> > > >
> > > > @@ -313,6 +314,7 @@ static void exynos_drm_unbind(struct device *dev)
> > > > drm_dev_unregister(drm);
> > > >
> > > > drm_kms_helper_poll_fini(drm);
> > > > + drm_atomic_helper_shutdown(drm);
> > > >
> > > > component_unbind_all(drm->dev, drm);
> > > > drm_mode_config_cleanup(drm);
> > > > @@ -350,9 +352,18 @@ static int exynos_drm_platform_remove(struct
> > > > platform_device *pdev)
> > > > return 0;
> > > > }
> > > >
> > > > +static void exynos_drm_platform_shutdown(struct platform_device *pdev)
> > > > +{
> > > > + struct drm_device *drm = platform_get_drvdata(pdev);
> > > > +
> > > > + if (drm)
> > > > + drm_atomic_helper_shutdown(drm);
> > > > +}
> > > > +
> > > > static struct platform_driver exynos_drm_platform_driver = {
> > > > .probe = exynos_drm_platform_probe,
> > > > .remove = exynos_drm_platform_remove,
> > > > + .shutdown = exynos_drm_platform_shutdown,
> > > > .driver = {
> > > > .name = "exynos-drm",
> > > > .pm = _drm_pm_ops,
> > >
> > > Best regards
> > > --
> > > Marek Szyprowski, PhD
> > > Samsung R Institute Poland
> > >
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just one fixup to a potential error pointer dereference. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 8a749fd1a8720d4619c91c8b6e7528c0a355c0aa: Linux 6.6-rc4 (2023-10-01 14:15:13 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.6-rc5 for you to fetch changes up to e49c384dc1c62fb5bf57c7bf6598957197e57919: drm/exynos: fix a potential error pointer dereference (2023-10-06 12:30:23 +0900) One fixup - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. Xiang Yang (1): drm/exynos: fix a potential error pointer dereference drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++ 1 file changed, 2 insertions(+)
Re: [PATCH] drm: exynos: dsi: Convert to platform remove callback returning void
2023년 9월 19일 (화) 오후 7:40, Uwe Kleine-König
님이 작성:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new() which already returns void. Eventually after all drivers
> are converted, .remove_new() is renamed to .remove().
>
> samsung_dsim_remove() returned 0 unconditionally. Make it return void
> instead to convert the two related platform drivers to use
> .remove_new().
>
> Signed-off-by: Uwe Kleine-König
It'd be better to go to drm-misc.
Reviewed-by: Inki Dae
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
> include/drm/bridge/samsung-dsim.h | 2 +-
> 3 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index b1df91e37b1b..2b56a5bfe273 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1998,7 +1998,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
> }
> EXPORT_SYMBOL_GPL(samsung_dsim_probe);
>
> -int samsung_dsim_remove(struct platform_device *pdev)
> +void samsung_dsim_remove(struct platform_device *pdev)
> {
> struct samsung_dsim *dsi = platform_get_drvdata(pdev);
>
> @@ -2006,8 +2006,6 @@ int samsung_dsim_remove(struct platform_device *pdev)
>
> if (dsi->plat_data->host_ops &&
> dsi->plat_data->host_ops->unregister_host)
> dsi->plat_data->host_ops->unregister_host(dsi);
> -
> - return 0;
> }
> EXPORT_SYMBOL_GPL(samsung_dsim_remove);
>
> @@ -2107,7 +2105,7 @@ MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
>
> static struct platform_driver samsung_dsim_driver = {
> .probe = samsung_dsim_probe,
> - .remove = samsung_dsim_remove,
> + .remove_new = samsung_dsim_remove,
> .driver = {
>.name = "samsung-dsim",
>.pm = _dsim_pm_ops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 69ea33cae651..2fe0e5f3f638 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -181,7 +181,7 @@ MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
>
> struct platform_driver dsi_driver = {
> .probe = samsung_dsim_probe,
> - .remove = samsung_dsim_remove,
> + .remove_new = samsung_dsim_remove,
> .driver = {
>.name = "exynos-dsi",
>.owner = THIS_MODULE,
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 6fc9bb2979e4..3f8050d523eb 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -116,7 +116,7 @@ struct samsung_dsim {
> };
>
> extern int samsung_dsim_probe(struct platform_device *pdev);
> -extern int samsung_dsim_remove(struct platform_device *pdev);
> +extern void samsung_dsim_remove(struct platform_device *pdev);
> extern const struct dev_pm_ops samsung_dsim_pm_ops;
>
> #endif /* __SAMSUNG_DSIM__ */
>
> base-commit: 0663e1da5ba8e6459e3555ac12c62741668c0d30
> --
> 2.40.1
>
Re: [RFT PATCH v2 09/12] drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time
Thanks for testing. :)
Acked-by : Inki Dae
2023년 9월 22일 (금) 오후 3:00, Marek Szyprowski 님이 작성:
>
>
> On 21.09.2023 21:26, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown time
> > and at driver unbind time. Among other things, this means that if a
> > panel is in use that it won't be cleanly powered off at system
> > shutdown time.
> >
> > The fact that we should call drm_atomic_helper_shutdown() in the case
> > of OS shutdown/restart and at driver remove (or unbind) time comes
> > straight out of the kernel doc "driver instance overview" in
> > drm_drv.c.
> >
> > A few notes about this fix:
> > - When adding drm_atomic_helper_shutdown() to the unbind path, I added
> >it after drm_kms_helper_poll_fini() since that's when other drivers
> >seemed to have it.
> > - Technically with a previous patch, ("drm/atomic-helper:
> >drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
> >actually need to check to see if our "drm" pointer is NULL before
> >calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
> >though, so that this patch can land without 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 Ripard
> > Signed-off-by: Douglas Anderson
>
> Seems to be working fine on all my test Exynos-based boards with display.
>
> Tested-by: Marek Szyprowski
>
> Reviewed-by: Marek Szyprowski
>
> > ---
> > This commit is only compile-time tested.
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index 8399256cb5c9..5380fb6c55ae 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -300,6 +300,7 @@ static int exynos_drm_bind(struct device *dev)
> > drm_mode_config_cleanup(drm);
> > exynos_drm_cleanup_dma(drm);
> > kfree(private);
> > + dev_set_drvdata(dev, NULL);
> > err_free_drm:
> > drm_dev_put(drm);
> >
> > @@ -313,6 +314,7 @@ static void exynos_drm_unbind(struct device *dev)
> > drm_dev_unregister(drm);
> >
> > drm_kms_helper_poll_fini(drm);
> > + drm_atomic_helper_shutdown(drm);
> >
> > component_unbind_all(drm->dev, drm);
> > drm_mode_config_cleanup(drm);
> > @@ -350,9 +352,18 @@ static int exynos_drm_platform_remove(struct
> > platform_device *pdev)
> > return 0;
> > }
> >
> > +static void exynos_drm_platform_shutdown(struct platform_device *pdev)
> > +{
> > + struct drm_device *drm = platform_get_drvdata(pdev);
> > +
> > + if (drm)
> > + drm_atomic_helper_shutdown(drm);
> > +}
> > +
> > static struct platform_driver exynos_drm_platform_driver = {
> > .probe = exynos_drm_platform_probe,
> > .remove = exynos_drm_platform_remove,
> > + .shutdown = exynos_drm_platform_shutdown,
> > .driver = {
> > .name = "exynos-drm",
> > .pm = _drm_pm_ops,
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
Re: [PATCH 2/5] drm/bridge: samsung-dsim: reread ref clock before configuring PLL
2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이 작성:
> The PLL reference clock may change at runtime. Thus, reading the clock
> rate during probe is not sufficient to correctly configure the PLL for
> the expected hs clock.
>
> Read the actual rate of the reference clock before calculating the PLL
> configuration parameters.
>
> Signed-off-by: Michael Tretter
>
Reviewed-by: Inki Dae
Acked-by: Inki Dae
Thanks,
Inki Dae
---
> drivers/gpu/drm/bridge/samsung-dsim.c | 16 +---
> include/drm/bridge/samsung-dsim.h | 1 +
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 6778f1751faa..da90c2038042 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -611,7 +611,12 @@ static unsigned long samsung_dsim_set_pll(struct
> samsung_dsim *dsi,
> u16 m;
> u32 reg;
>
> - fin = dsi->pll_clk_rate;
> + if (dsi->pll_clk)
> + fin = clk_get_rate(dsi->pll_clk);
> + else
> + fin = dsi->pll_clk_rate;
> + dev_dbg(dsi->dev, "PLL ref clock freq %lu\n", fin);
> +
> fout = samsung_dsim_pll_find_pms(dsi, fin, freq, , , );
> if (!fout) {
> dev_err(dsi->dev,
> @@ -1821,18 +1826,15 @@ static int samsung_dsim_parse_dt(struct
> samsung_dsim *dsi)
> u32 lane_polarities[5] = { 0 };
> struct device_node *endpoint;
> int i, nr_lanes, ret;
> - struct clk *pll_clk;
>
> ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
>>pll_clk_rate, 1);
> /* If it doesn't exist, read it from the clock instead of failing
> */
> if (ret < 0) {
> dev_dbg(dev, "Using sclk_mipi for pll clock frequency\n");
> - pll_clk = devm_clk_get(dev, "sclk_mipi");
> - if (!IS_ERR(pll_clk))
> - dsi->pll_clk_rate = clk_get_rate(pll_clk);
> - else
> - return PTR_ERR(pll_clk);
> + dsi->pll_clk = devm_clk_get(dev, "sclk_mipi");
> + if (IS_ERR(dsi->pll_clk))
> + return PTR_ERR(dsi->pll_clk);
> }
>
> /* If it doesn't exist, use pixel clock instead of failing */
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 05100e91ecb9..31ff88f152fb 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -87,6 +87,7 @@ struct samsung_dsim {
> void __iomem *reg_base;
> struct phy *phy;
> struct clk **clks;
> + struct clk *pll_clk;
> struct regulator_bulk_data supplies[2];
> int irq;
> struct gpio_desc *te_gpio;
>
> --
> 2.39.2
>
>
Re: [PATCH 2/5] drm/bridge: samsung-dsim: reread ref clock before configuring PLL
2023년 9월 4일 (월) 오후 8:05, Michael Tretter 님이 작성:
> On Mon, 04 Sep 2023 13:38:33 +0900, Inki Dae wrote:
> > 2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이
> 작성:
> >
> > >
> > > The PLL reference clock may change at runtime. Thus, reading the clock
> > > rate during probe is not sufficient to correctly configure the PLL for
> > > the expected hs clock.
> > >
> > > Read the actual rate of the reference clock before calculating the PLL
> > > configuration parameters.
> > >
> > > Signed-off-by: Michael Tretter
> > > ---
> > > drivers/gpu/drm/bridge/samsung-dsim.c | 16 +---
> > > include/drm/bridge/samsung-dsim.h | 1 +
> > > 2 files changed, 10 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > index 6778f1751faa..da90c2038042 100644
> > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > @@ -611,7 +611,12 @@ static unsigned long samsung_dsim_set_pll(struct
> samsung_dsim *dsi,
> > > u16 m;
> > > u32 reg;
> > >
> > > - fin = dsi->pll_clk_rate;
> > > + if (dsi->pll_clk)
> > > + fin = clk_get_rate(dsi->pll_clk);
> > > + else
> > > + fin = dsi->pll_clk_rate;
> > > + dev_dbg(dsi->dev, "PLL ref clock freq %lu\n", fin);
> > > +
> >
> > Could you share us the actual use case that in runtime the pll
> > reference clock can be changed?
>
> On i.MX8M Nano, the VIDEO_PLL_CLK drives the DISPLAY_PIXEL_CLK_ROOT, which
> is
> used as pixel clock by the LCDIF. Changes to the pixel clock propagate to
> the
> VIDEO_PLL_CLK and may reconfigure the VIDEO_PLL_CLK. This is done to reduce
> the error on the pixel clock.
>
> As the ADV3575 as MIPI-DSI device reconstructs the pixel clock, it is
> necessary to keep the pixel clock and MIDI-DSI reference clock in
> sync. This can be done by using the VIDEO_PLL_CLK to drive the PLL
> reference
> clock (MIPI_DSI_CORE_CLK_ROOT). Without this, a connected HDMI Monitor will
> occasionally loose sync.
>
> In this setup, a mode change that changes the pixel clock may change the
> VIDEO_PLL, which will change the PLL reference clock.
>
Thanks for sharing.
> >
> > This patch is trying to change clock binding behavior which is
> > described in dt binding[1]
> > [1]
> Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
> >
> > It says,
> > "DISM oscillator clock frequency. If absent, the clock frequency of
> > sclk_mipi will be used instead."
> >
> > However, this patch makes the sclk_mipi to be used first.
>
> No, the behavior, as described in the dt binding, is preserved by the hunk
> below. dsi->pll_clk is only set, if the samsung,pll-clock-frequency
> property
> is absent. If the dt property exists, dsi->pll_clk will be NULL and
> dsi->pll_clk_rate will be used here.
>
It's true. No behavior change. There was my mistake. Thanks. :)
> Michael
>
> >
> > Thanks,
> > Inki Dae
> >
> > > fout = samsung_dsim_pll_find_pms(dsi, fin, freq, , , );
> > > if (!fout) {
> > > dev_err(dsi->dev,
> > > @@ -1821,18 +1826,15 @@ static int samsung_dsim_parse_dt(struct
> samsung_dsim *dsi)
> > > u32 lane_polarities[5] = { 0 };
> > > struct device_node *endpoint;
> > > int i, nr_lanes, ret;
> > > - struct clk *pll_clk;
> > >
> > > ret = samsung_dsim_of_read_u32(node,
> "samsung,pll-clock-frequency",
> > >>pll_clk_rate, 1);
> > > /* If it doesn't exist, read it from the clock instead of
> failing */
> > > if (ret < 0) {
> > > dev_dbg(dev, "Using sclk_mipi for pll clock
> frequency\n");
> > > - pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > - if (!IS_ERR(pll_clk))
> > > - dsi->pll_clk_rate = clk_get_rate(pll_clk);
> > > - else
> > > - return PTR_ERR(pll_clk);
> > > + dsi->pll_clk = devm_clk_get(dev, "sclk_mipi");
> > > + if (IS_ERR(dsi->pll_clk))
> > > + return PTR_ERR(dsi->pll_clk);
> > > }
> > >
> > > /* If it doesn't exist, use pixel clock instead of failing */
> > > diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> > > index 05100e91ecb9..31ff88f152fb 100644
> > > --- a/include/drm/bridge/samsung-dsim.h
> > > +++ b/include/drm/bridge/samsung-dsim.h
> > > @@ -87,6 +87,7 @@ struct samsung_dsim {
> > > void __iomem *reg_base;
> > > struct phy *phy;
> > > struct clk **clks;
> > > + struct clk *pll_clk;
> > > struct regulator_bulk_data supplies[2];
> > > int irq;
> > > struct gpio_desc *te_gpio;
> > >
> > > --
> > > 2.39.2
> > >
> >
>
Re: [PATCH 3/5] drm/bridge: samsung-dsim: update PLL reference clock
2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이 작성:
>
> The PLL requires a clock between 2 MHz and 30 MHz after the pre-divider.
> The reference clock for the PLL may change due to changes to it's parent
> clock. Thus, the frequency may be out of range or unsuited for
> generating the high speed clock for MIPI DSI.
>
> Try to keep the pre-devider small, and set the reference clock close to
> 30 MHz before recalculating the PLL configuration. Use a divider with a
> power of two for the reference clock as this seems to work best in
> my tests.
Clock frequency is specific to SoC architecture so we have to handle
it carefully because samsung-dsim.c is a common module for I.MX and
Exynos series.
You mentioned "The PLL requires a clock between 2 MHz and 3MHz after
pre-divider", and the clock means that fin_pll - PFD input frequency -
which can be calculated with oscillator clock frequency / P value?
According to Exynos datasheet, the fin_pll should be 6 ~ 12Mhz.
For example,
In case of Exyhos, we use 24MHz as oscillator clock frequency, so
fin_pll frequency, 8MHz = 24MHz / P(3).
Can you tell me the source of the constraint that clocks must be
between 2MHz and 30MHz?
To other I.MX and Exynos engineers, please do not merge this patch
until two SoC platforms are tested correctly.
Thanks,
Inki Dae
>
> Signed-off-by: Michael Tretter
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index da90c2038042..4de6e4f116db 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -611,10 +611,21 @@ static unsigned long samsung_dsim_set_pll(struct
> samsung_dsim *dsi,
> u16 m;
> u32 reg;
>
> - if (dsi->pll_clk)
> + if (dsi->pll_clk) {
> + /*
> +* Ensure that the reference clock is generated with a power
> of
> +* two divider from its parent, but close to the PLLs upper
> +* limit of the valid range of 2 MHz to 30 MHz.
> +*/
> + fin = clk_get_rate(clk_get_parent(dsi->pll_clk));
> + while (fin > 30 * MHZ)
> + fin = fin / 2;
> + clk_set_rate(dsi->pll_clk, fin);
> +
> fin = clk_get_rate(dsi->pll_clk);
> - else
> + } else {
> fin = dsi->pll_clk_rate;
> + }
> dev_dbg(dsi->dev, "PLL ref clock freq %lu\n", fin);
>
> fout = samsung_dsim_pll_find_pms(dsi, fin, freq, , , );
>
> --
> 2.39.2
>
Re: [PATCH 2/5] drm/bridge: samsung-dsim: reread ref clock before configuring PLL
2023년 8월 29일 (화) 오전 12:59, Michael Tretter 님이 작성:
>
> The PLL reference clock may change at runtime. Thus, reading the clock
> rate during probe is not sufficient to correctly configure the PLL for
> the expected hs clock.
>
> Read the actual rate of the reference clock before calculating the PLL
> configuration parameters.
>
> Signed-off-by: Michael Tretter
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 16 +---
> include/drm/bridge/samsung-dsim.h | 1 +
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 6778f1751faa..da90c2038042 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -611,7 +611,12 @@ static unsigned long samsung_dsim_set_pll(struct
> samsung_dsim *dsi,
> u16 m;
> u32 reg;
>
> - fin = dsi->pll_clk_rate;
> + if (dsi->pll_clk)
> + fin = clk_get_rate(dsi->pll_clk);
> + else
> + fin = dsi->pll_clk_rate;
> + dev_dbg(dsi->dev, "PLL ref clock freq %lu\n", fin);
> +
Could you share us the actual use case that in runtime the pll
reference clock can be changed?
This patch is trying to change clock binding behavior which is
described in dt binding[1]
[1] Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
It says,
"DISM oscillator clock frequency. If absent, the clock frequency of
sclk_mipi will be used instead."
However, this patch makes the sclk_mipi to be used first.
Thanks,
Inki Dae
> fout = samsung_dsim_pll_find_pms(dsi, fin, freq, , , );
> if (!fout) {
> dev_err(dsi->dev,
> @@ -1821,18 +1826,15 @@ static int samsung_dsim_parse_dt(struct samsung_dsim
> *dsi)
> u32 lane_polarities[5] = { 0 };
> struct device_node *endpoint;
> int i, nr_lanes, ret;
> - struct clk *pll_clk;
>
> ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
>>pll_clk_rate, 1);
> /* If it doesn't exist, read it from the clock instead of failing */
> if (ret < 0) {
> dev_dbg(dev, "Using sclk_mipi for pll clock frequency\n");
> - pll_clk = devm_clk_get(dev, "sclk_mipi");
> - if (!IS_ERR(pll_clk))
> - dsi->pll_clk_rate = clk_get_rate(pll_clk);
> - else
> - return PTR_ERR(pll_clk);
> + dsi->pll_clk = devm_clk_get(dev, "sclk_mipi");
> + if (IS_ERR(dsi->pll_clk))
> + return PTR_ERR(dsi->pll_clk);
> }
>
> /* If it doesn't exist, use pixel clock instead of failing */
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 05100e91ecb9..31ff88f152fb 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -87,6 +87,7 @@ struct samsung_dsim {
> void __iomem *reg_base;
> struct phy *phy;
> struct clk **clks;
> + struct clk *pll_clk;
> struct regulator_bulk_data supplies[2];
> int irq;
> struct gpio_desc *te_gpio;
>
> --
> 2.39.2
>
Re: [PATCH 1/5] drm/bridge: samsung-dsim: add more mipi-dsi device debug information
2023년 8월 29일 (화) 오전 7:38, Adam Ford 님이 작성: > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter > wrote: > > > > From: Marco Felsch > > > > Since the MIPI configuration can be changed on demand it is very useful > > to print more MIPI settings during the MIPI device attach step. > > > > Signed-off-by: Marco Felsch > > Signed-off-by: Michael Tretter > > Reviewed-by: Adam Ford #imx8mm-beacon > Tested-by: Adam Ford #imx8mm-beacon Reviewed-by: Inki Dae Acked-by: Inki Dae > > > --- > > drivers/gpu/drm/bridge/samsung-dsim.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > > b/drivers/gpu/drm/bridge/samsung-dsim.c > > index 73ec60757dbc..6778f1751faa 100644 > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > @@ -1711,7 +1711,10 @@ static int samsung_dsim_host_attach(struct > > mipi_dsi_host *host, > > return ret; > > } > > > > - DRM_DEV_INFO(dev, "Attached %s device\n", device->name); > > + DRM_DEV_INFO(dev, "Attached %s device (lanes:%d bpp:%d > > mode-flags:0x%lx)\n", > > +device->name, device->lanes, > > +mipi_dsi_pixel_format_to_bpp(device->format), > > +device->mode_flags); > > > > drm_bridge_add(>bridge); > > > > > > -- > > 2.39.2 > >
Re: [PATCH -next] drm/exynos: fix a potential error pointer dereference
2023년 8월 12일 (토) 오후 4:17, Xiang Yang 님이 작성: > From: Xiang Yang > > Smatch reports the warning below: > drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind() > error: 'crtc' dereferencing possible ERR_PTR() > > The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV), > which can not be used directly. Fix this by checking the return value > before using it. > Applied. Thanks, Inki Dae > > Signed-off-by: Xiang Yang > --- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index f3aaa4ea3e68..dd9903eab563 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -1861,6 +1861,8 @@ static int hdmi_bind(struct device *dev, struct > device *master, void *data) > return ret; > > crtc = exynos_drm_crtc_get_by_type(drm_dev, > EXYNOS_DISPLAY_TYPE_HDMI); > + if (IS_ERR(crtc)) > + return PTR_ERR(crtc); > crtc->pipe_clk = >phy_clk; > > ret = hdmi_create_connector(encoder); > -- > 2.34.1 > >
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one fixup and cleanup. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit d9aa1da9a8cfb0387eb5703c15bd1f54421460ac: Merge tag 'drm-intel-gt-next-2023-08-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-08-07 13:49:25 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.6 for you to fetch changes up to 6b83c85b64078ff49b4d3d0b2cd2c2bf6f1b6a85: drm/exynos: remove redundant of_match_ptr (2023-08-08 09:35:19 +0900) Fixup - fix a possible null pointer dereference issue in exynos_drm_crtc_atomic_disable(), which was reported by the automatic static analysis tool. And below is a relevant link, https://sites.google.com/view/basscheck/home Cleanup - drop the use of of_match_ptr which is redundant. Tuo Li (1): drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable() Zhu Wang (1): drm/exynos: remove redundant of_match_ptr drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-)
Re: [PATCH -next] drm/exynos: remove redundant of_match_ptr
2023년 7월 31일 (월) 오후 10:09, Krzysztof Kozlowski < krzysztof.kozlow...@linaro.org>님이 작성: > On 31/07/2023 14:33, Zhu Wang wrote: > > The driver depends on CONFIG_OF, so it is not necessary to use > > of_match_ptr here. > > > > Even for drivers that do not depend on CONFIG_OF, it's almost always > > better to leave out the of_match_ptr(), since the only thing it can > > possibly do is to save a few bytes of .text if a driver can be used both > > with and without it. Hence we remove of_match_ptr. > > > > Signed-off-by: Zhu Wang > > > Reviewed-by: Krzysztof Kozlowski > Merged. Thanks, Inki Dae > Best regards, > Krzysztof > >
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just two fixups to Exynos vidi and g2d drivers. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 9561de3a55bed6bdd44a12820ba81ec416e705a7: Linux 6.4-rc5 (2023-06-04 14:04:27 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.4-rc6 for you to fetch changes up to 48bfd02569f5db49cc033f259e66d57aa6efc9a3: drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl (2023-06-07 13:03:16 +0900) Two fixups - Fix wrong return in Exynos vidi driver. - Fix use-after-free issue to Exynos g2d driver. Inki Dae (1): drm/exynos: vidi: fix a wrong error return Min Li (1): drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-)
Re: [PATCH] drm/exynos: vidi: fix a wrong error return
2023년 5월 19일 (금) 오후 6:21, Andi Shyti 님이 작성:
> Hi Inki,
>
> > > > @@ -469,8 +469,6 @@ static int vidi_remove(struct platform_device
> *pdev)
> > > > if (ctx->raw_edid != (struct edid *)fake_edid_info) {
> > > > kfree(ctx->raw_edid);
> > > > ctx->raw_edid = NULL;
> > > > -
> > > > - return -EINVAL;
> > >
> > > It doesn't look right to me, I think the correct patch should be:
> > >
> > > - if (ctx->raw_edid != (struct edid *)fake_edid_info) {
> > > - kfree(ctx->raw_edid);
> > > - ctx->raw_edid = NULL;
> > > -
> > > - return -EINVAL;
> > > - }
> > > -
> > > + ctx->raw_edid = NULL;
> > >
> > > because "ctx->raw_edid" points to a non allocated memory in the
> > > .data segment and you cannot free it.
> > >
> > > A follow-up cleanup should be to remove the "const" from
> > > fake_edid_info because you are assigning its address to pointers
> > > (raw_edid), so that what's the point for having it const? You are
> > > just fooling the compiler :)
> >
> > Thanks for review comment.
> >
> > "ctx->raw_edid != fake_edid_info" means that the edid sent by the user
> through
> > the ictl system call - vidi_connection_ioctl - is used instead of fake
> one -
> > face_edid_info.
> > In this case, ctx->raw_edid object needs to be released because
> ctx->raw_edid
> > object is allocated and the edid object sent by user is copied to the
> ctx-
> > >raw_edid by kmemdup(). :)
>
> yes... yes... I sent you another e-mail after this :)
>
I didn't check the second email you sent. :)
Thanks,
Inki Dae
> Thanks,
> Andi
>
[PATCH] drm/exynos: vidi: fix a wrong error return
Fix a wrong error return by dropping an error return.
When vidi driver is remvoed, if ctx->raw_edid isn't same as fake_edid_info
then only what we have to is to free ctx->raw_edid so that driver removing
can work correctly - it's not an error case.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4d56c8c799c5..f5e1adfcaa51 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -469,8 +469,6 @@ static int vidi_remove(struct platform_device *pdev)
if (ctx->raw_edid != (struct edid *)fake_edid_info) {
kfree(ctx->raw_edid);
ctx->raw_edid = NULL;
-
- return -EINVAL;
}
component_del(>dev, _component_ops);
--
2.25.1
Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
Hi, 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König 님이 작성: > > Hello, > > this patch series adapts the platform drivers below drivers/gpu/drm > to use the .remove_new() callback. Compared to the traditional .remove() > callback .remove_new() returns no value. This is a good thing because First of all, I apologize for the delay in providing my review comments. Not related to this patch but seems that the "remove_new" callback naming implicitly implies that there is no need to return anything since its return type is void. To help users understand the intended behavior based on the callback name, how about considering a modified naming convention like "remove_no_return" or something similar? The relevant patch has already been merged as outlined below, author Uwe Kleine-König 2022-12-09 16:09:14 +0100 committer Greg Kroah-Hartman 2023-01-17 19:04:17 +0100 commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch) tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff) download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz platform: Provide a remove callback that returns no value Maybe a trivial thing but how about renaming it? I think the postfix, 'new', is a very generic word. I think you could introduce another patch for it if you think it's reasonable. Thanks, Inki Dae > the driver core doesn't (and cannot) cope for errors during remove. The > only effect of a non-zero return value in .remove() is that the driver > core emits a warning. The device is removed anyhow and an early return > from .remove() usually yields a resource leak. > > By changing the remove callback to return void driver authors cannot > reasonably (but wrongly) assume any more that there happens some kind of > cleanup later. > > Best regards > Uwe > > Uwe Kleine-König (53): > drm/komeda: Convert to platform remove callback returning void > drm/arm/hdlcd: Convert to platform remove callback returning void > drm/arm/malidp: Convert to platform remove callback returning void > drm/armada: Convert to platform remove callback returning void > drm/aspeed: Convert to platform remove callback returning void > drm/atmel-hlcdc: Convert to platform remove callback returning void > drm/bridge: cdns-dsi: Convert to platform remove callback returning > void > drm/bridge: display-connector: Convert to platform remove callback > returning void > drm/bridge: fsl-ldb: Convert to platform remove callback returning > void > drm/imx/imx8*: Convert to platform remove callback returning void > drm/bridge: lvds-codec: Convert to platform remove callback returning > void > drm/bridge: nwl-dsi: Convert to platform remove callback returning > void > drm/bridge: simple-bridge: Convert to platform remove callback > returning void > drm/bridge: synopsys: Convert to platform remove callback returning > void > drm/bridge: thc63lvd1024: Convert to platform remove callback > returning void > drm/bridge: tfp410: Convert to platform remove callback returning void > drm/etnaviv: Convert to platform remove callback returning void > drm/exynos: Convert to platform remove callback returning void > drm/fsl-dcu: Convert to platform remove callback returning void > drm/hisilicon: Convert to platform remove callback returning void > drm/imx/dcss: Convert to platform remove callback returning void > drm/imx/ipuv3: Convert to platform remove callback returning void > drm/ingenic: Convert to platform remove callback returning void > drm/kmb: Convert to platform remove callback returning void > drm/lima: Convert to platform remove callback returning void > drm/logicvc: Convert to platform remove callback returning void > drm/mcde: Convert to platform remove callback returning void > drm/mediatek: Convert to platform remove callback returning void > drm/mediatek: Convert to platform remove callback returning void > drm/meson: Convert to platform remove callback returning void > drm/msm: Convert to platform remove callback returning void > drm/mxsfb: Convert to platform remove callback returning void > drm/nouveau: Convert to platform remove callback returning void > drm/omap: Convert to platform remove callback returning void > drm/panel: Convert to platform remove callback returning void > drm/panfrost: Convert to platform remove callback returning void > drm/rcar-du: Convert to platform remove callback returning void > drm/rockchip: Convert to platform remove callback returning void > drm/shmobile: Convert to platform remove callback returning void > drm/sprd: Convert to platform remove callback returning void > drm/sti: Convert to platform remove callback returning void > drm/stm: Conver
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just one fixup to graphics 2d module for exynos. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit d8843eebbbd15b78c6a7745717b3705eca923b0f: Merge tag 'amd-drm-fixes-6.4-2023-05-11' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-05-12 06:46:34 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.4-rc3 for you to fetch changes up to 2ef0785b30bd6549ddbc124979f1b6596e065ae2: drm/exynos: fix g2d_open/close helper function definitions (2023-05-15 14:10:34 +0900) Just one fixup to exynos_drm_g2d module. - Fix below build warning by marking them as 'static inline' drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype for 'g2d_open' drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:5: error: no previous prototype for 'g2d_close' Arnd Bergmann (1): drm/exynos: fix g2d_open/close helper function definitions drivers/gpu/drm/exynos/exynos_drm_g2d.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
Hi,
2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König 님이 작성:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the exynos drm drivers from always returning zero in
> the remove callback to the void returning variant.
Could you please update exynos_drm_vidi.c also? Seems you missed.
Thanks,
Inki Dae
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 ++
> drivers/gpu/drm/exynos/exynos_dp.c| 6 ++
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++
> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 ++
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++
> 14 files changed, 28 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2867b39fa35e..dd63418a9fd2 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> -static int exynos5433_decon_remove(struct platform_device *pdev)
> +static void exynos5433_decon_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(>dev);
>
> component_del(>dev, _component_ops);
> -
> - return 0;
> }
>
> struct platform_driver exynos5433_decon_driver = {
> .probe = exynos5433_decon_probe,
> - .remove = exynos5433_decon_remove,
> + .remove_new = exynos5433_decon_remove,
> .driver = {
> .name = "exynos5433-decon",
> .pm = pm_ptr(_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 3126f735dedc..6fca23e04285 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int decon_remove(struct platform_device *pdev)
> +static void decon_remove(struct platform_device *pdev)
> {
> struct decon_context *ctx = dev_get_drvdata(>dev);
>
> @@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
> iounmap(ctx->regs);
>
> component_del(>dev, _component_ops);
> -
> - return 0;
> }
>
> static int exynos7_decon_suspend(struct device *dev)
> @@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops,
> exynos7_decon_suspend,
>
> struct platform_driver decon_driver = {
> .probe = decon_probe,
> - .remove = decon_remove,
> + .remove_new = decon_remove,
> .driver = {
> .name = "exynos-decon",
> .pm = pm_ptr(_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 3404ec1367fb..ca31bad6c576 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
> return component_add(>dev, _dp_ops);
> }
>
> -static int exynos_dp_remove(struct platform_device *pdev)
> +static void exynos_dp_remove(struct platform_device *pdev)
> {
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> component_del(>dev, _dp_ops);
> analogix_dp_remove(dp->adp);
> -
> - return 0;
> }
>
> static int exynos_dp_suspend(struct device *dev)
> @@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
>
> struct
Re: [PATCH] drm/exynos: g2d: staticize stubs in header
2023년 5월 15일 (월) 오후 1:13, Inki Dae 님이 작성:
>
> Hi Krzysztof,
>
> 2023년 5월 7일 (일) 오후 11:48, Krzysztof Kozlowski
> 님이 작성:
> >
> > Stubs for !CONFIG_DRM_EXYNOS_G2D case in the header should be static
> > inline:
>
> Same patch[1] was posted before so I picked up the previous one.
>
> [1] [PATCH] drm/exynos: fix g2d_open/close helper function definitions
> (kernel.org)
[1] https://lore.kernel.org/lkml/20230425165618.2ztg4mecuvpkdg3a@intel.intel/T/
Just corrected the link.
>
> Thanks,
> Inki Dae
>
> >
> > drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: warning: no previous
> > prototype for ‘g2d_open’ [-Wmissing-prototypes]
> > drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:6: warning: no previous
> > prototype for ‘g2d_close’ [-Wmissing-prototypes]
> >
> > Fixes: eb4d9796fa34 ("drm/exynos: g2d: Convert to driver component API")
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_g2d.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> > b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> > index 74ea3c26dead..1a5ae781b56c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> > @@ -34,11 +34,11 @@ static inline int exynos_g2d_exec_ioctl(struct
> > drm_device *dev, void *data,
> > return -ENODEV;
> > }
> >
> > -int g2d_open(struct drm_device *drm_dev, struct drm_file *file)
> > +static inline int g2d_open(struct drm_device *drm_dev, struct drm_file
> > *file)
> > {
> > return 0;
> > }
> >
> > -void g2d_close(struct drm_device *drm_dev, struct drm_file *file)
> > +static inline void g2d_close(struct drm_device *drm_dev, struct drm_file
> > *file)
> > { }
> > #endif
> > --
> > 2.34.1
> >
Re: [PATCH] drm/exynos: g2d: staticize stubs in header
Hi Krzysztof,
2023년 5월 7일 (일) 오후 11:48, Krzysztof Kozlowski
님이 작성:
>
> Stubs for !CONFIG_DRM_EXYNOS_G2D case in the header should be static
> inline:
Same patch[1] was posted before so I picked up the previous one.
[1] [PATCH] drm/exynos: fix g2d_open/close helper function definitions
(kernel.org)
Thanks,
Inki Dae
>
> drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: warning: no previous
> prototype for ‘g2d_open’ [-Wmissing-prototypes]
> drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:6: warning: no previous
> prototype for ‘g2d_close’ [-Wmissing-prototypes]
>
> Fixes: eb4d9796fa34 ("drm/exynos: g2d: Convert to driver component API")
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> index 74ea3c26dead..1a5ae781b56c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.h
> @@ -34,11 +34,11 @@ static inline int exynos_g2d_exec_ioctl(struct drm_device
> *dev, void *data,
> return -ENODEV;
> }
>
> -int g2d_open(struct drm_device *drm_dev, struct drm_file *file)
> +static inline int g2d_open(struct drm_device *drm_dev, struct drm_file *file)
> {
> return 0;
> }
>
> -void g2d_close(struct drm_device *drm_dev, struct drm_file *file)
> +static inline void g2d_close(struct drm_device *drm_dev, struct drm_file
> *file)
> { }
> #endif
> --
> 2.34.1
>
[GIT PULL v2] exynos-drm-next
Hi Dave and Daniel, Sorry for late. Just one patch series which converts Exynos's fbdev code to struct drm_client. Please let me know if there is any problem. Thanks, Inki Dae The following changes since commit e82c98f2ca439356d5595ba8c9cd782f993f6f8c: Merge tag 'amd-drm-next-6.4-2023-04-14' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-04-17 10:54:59 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.4-2 for you to fetch changes up to 49953b70e7d38dd714f4cf4e8a7ce14f3c48: drm/exynos: Implement fbdev emulation as in-kernel client (2023-04-17 16:47:55 +0900) A patch series for implementing fbdev emulation as in-kernel client. - This patch series refactors fbdev callbacks to DRM client functions and simplifies fbdev emulation initialization including some code cleanups. The changes make fbdev emulation behave like a regular DRM client. Thomas Zimmermann (5): drm/exynos: Remove exynos_gem from struct exynos_drm_fbdev drm/exynos: Remove struct exynos_drm_fbdev drm/exynos: Remove fb_helper from struct exynos_drm_private drm/exynos: Initialize fbdev DRM client drm/exynos: Implement fbdev emulation as in-kernel client drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 +-- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 - drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 174 +++--- drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 20 +--- 5 files changed, 94 insertions(+), 117 deletions(-)
Re: [GIT PULL] exynos-drm-next
Hi Daniel, 2023년 3월 29일 (수) 오후 2:39, 대인기 님이 작성: > > > > > -Original Message- > > From: Daniel Vetter > > Sent: Wednesday, March 29, 2023 2:31 AM > > To: Inki Dae > > Cc: airl...@linux.ie; dan...@ffwll.ch; dri-devel@lists.freedesktop.org; > > linux-samsung-...@vger.kernel.org > > Subject: Re: [GIT PULL] exynos-drm-next > > > > On Tue, Mar 28, 2023 at 01:05:24PM +0900, Inki Dae wrote: > > > Hi Dave and Daniel, > > > > > >Just one patch series that moves the existing Exynos DSI driver > > >to drm/bridge directory to support both SoCs family - Exynos > > >and I.MX - because same Exynos MIPI DSI ip can be used by the two > > >different SoC family. > > > > > >Of course, there are some concerns about this patch series because > > Exynos > > >and I.MX SoCs have different HW characteristic but use the same HW > > driver. > > >However, I believe that there should be no problem as Exynos and I.MX > > >developers have conducted tests and reviews enough for about a year > > >since last April. > > > > > >This would be the first case that we allow different vendor SoCs to use > > >same device driver at least in DRM world so we anticipate experiencing > > >and resolving new issues through ongoing maintenance, and ultimately, > > >the experiences gained here will undoubtedly be able to contribute > > >the development of the community as well. > > > > > >Please kindly let me know if there is any problem. > > > > > > Thanks, > > > Inki Dae Could you kindly help me understand if there are any missed steps on my part? I applied for commit access to the drm and drm-misc repositories through the link provided below two weeks ago, but haven't received any updates on my request. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/569 Thanks, Inki Dae > > > > > > The following changes since commit > > 46f28427f6f824b6cff06fa025a55350b7de454a: > > > > > > Merge tag 'drm-rcar-next-20230325' of > > git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next > > (2023-03-27 18:20:20 +0200) > > > > > > are available in the Git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > > tags/exynos-drm-next-for-v6.4 > > > > Merged, but usually all drm bridge stuff goes through drm-misc, least so > > that there's some amount of collaboration and not so much inter-tree > > syncing. > > > > Please apply for drm-misc commit rights (at least a quick check shows no > > one from samsung) and land future bridge patches through that tree. > > > > Cheers, Daniel > > I will apply for drm-misc commit rights. :) > > Thanks, > Inki Dae > > > > > > > > > for you to fetch changes up to b2cfec52feb3bb737c4b65018ef4bfe9789e4be8: > > > > > > drm: bridge: samsung-dsim: Add i.MX8M Plus support (2023-03-28 09:05:41 > > +0900) > > > > > > > > > A patch series for moving MIPI-DSI driver for Exynos DRM to drm/bridge > > > directory so that I.MX SoC family can also share the same device driver. > > > Samsung MIPI DSIM device is a common IP that can be used by Exynos and > > I.MX8M > > > Mini/Nano/Plus SoC. Regarding this, this patch series has added several > > > things below to existing MIPI DSI driver, > > > - Add exynos_dsi_type enum type to provide controller data from > > different > > > platforms. > > > - Add two pipeline detection ways support - existing Exynos DSI child > > node > > > and I.MX family of-graph port or ports. > > > - Consider component and bridged based DRM drivers. > > > - Add device tree binding support of I.MX family. > > > > > > > > > Jagan Teki (14): > > > drm: exynos: dsi: Drop explicit call to bridge detach > > > drm: exynos: dsi: Lookup OF-graph or Child node devices > > > drm: exynos: dsi: Mark PHY as optional > > > drm: exynos: dsi: Add platform PLL_P (PMS_P) offset > > > drm: exynos: dsi: Introduce hw_type platform data > > > drm: exynos: dsi: Add atomic check > > > drm: exynos: dsi: Add input_bus_flags > > > drm: exynos: dsi: Add atomic_ge
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one patch series that moves the existing Exynos DSI driver to drm/bridge directory to support both SoCs family - Exynos and I.MX - because same Exynos MIPI DSI ip can be used by the two different SoC family. Of course, there are some concerns about this patch series because Exynos and I.MX SoCs have different HW characteristic but use the same HW driver. However, I believe that there should be no problem as Exynos and I.MX developers have conducted tests and reviews enough for about a year since last April. This would be the first case that we allow different vendor SoCs to use same device driver at least in DRM world so we anticipate experiencing and resolving new issues through ongoing maintenance, and ultimately, the experiences gained here will undoubtedly be able to contribute the development of the community as well. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 46f28427f6f824b6cff06fa025a55350b7de454a: Merge tag 'drm-rcar-next-20230325' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next (2023-03-27 18:20:20 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.4 for you to fetch changes up to b2cfec52feb3bb737c4b65018ef4bfe9789e4be8: drm: bridge: samsung-dsim: Add i.MX8M Plus support (2023-03-28 09:05:41 +0900) A patch series for moving MIPI-DSI driver for Exynos DRM to drm/bridge directory so that I.MX SoC family can also share the same device driver. Samsung MIPI DSIM device is a common IP that can be used by Exynos and I.MX8M Mini/Nano/Plus SoC. Regarding this, this patch series has added several things below to existing MIPI DSI driver, - Add exynos_dsi_type enum type to provide controller data from different platforms. - Add two pipeline detection ways support - existing Exynos DSI child node and I.MX family of-graph port or ports. - Consider component and bridged based DRM drivers. - Add device tree binding support of I.MX family. Jagan Teki (14): drm: exynos: dsi: Drop explicit call to bridge detach drm: exynos: dsi: Lookup OF-graph or Child node devices drm: exynos: dsi: Mark PHY as optional drm: exynos: dsi: Add platform PLL_P (PMS_P) offset drm: exynos: dsi: Introduce hw_type platform data drm: exynos: dsi: Add atomic check drm: exynos: dsi: Add input_bus_flags drm: exynos: dsi: Add atomic_get_input_bus_fmts drm: exynos: dsi: Consolidate component and bridge drm: exynos: dsi: Add host helper for te_irq_handler drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support Marek Szyprowski (1): drm: exynos: dsi: Handle proper host initialization Marek Vasut (1): drm: bridge: samsung-dsim: Add i.MX8M Plus support .../bindings/display/exynos/exynos_dsim.txt|2 + MAINTAINERS|9 + drivers/gpu/drm/bridge/Kconfig | 12 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/samsung-dsim.c | 1967 drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1813 +- include/drm/bridge/samsung-dsim.h | 115 ++ 8 files changed, 2191 insertions(+), 1729 deletions(-) create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c create mode 100644 include/drm/bridge/samsung-dsim.h
Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge
Hi, 2023년 3월 27일 (월) 오후 11:08, Neil Armstrong 님이 작성: > On 23/03/2023 16:34, Fabio Estevam wrote: > > Hi Inki, > > > > On Mon, Mar 13, 2023 at 9:51 PM Inki Dae wrote: > > > >>> Could you please apply v16? > >> > >> > >> I am planning to merge this patch series soon, but I will be proceeding > with the pull-request next week. As the DSIM driver is being moved to the > bridge folder, I would like to wait for acknowledgment from the bridge > maintainers. However, if there are no further comments until next week, I > will proceed with the pull-request. > > > > A friendly reminder: do you think you can proceed with the pull-request > now? > > I can apply the entire patchset to drm-misc-needed if needed. > > Inki, is it ok for you or you still want to take it in the exynos tree ? > Sorry for late. I will proceed with pull-request today. BTW, now is rc4 so we have more time for pull-request. Is there any reason you hurry up? Thanks, Inki Dae > Neil > > > > > Thanks > >
Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge
Hi Fabio Estevam, 2023년 3월 14일 (화) 오전 9:31, Fabio Estevam 님이 작성: > Hi Inki, > > On Mon, Mar 6, 2023 at 2:24 AM 대인기/Tizen Platform Lab(SR)/삼성전자 > wrote: > > > Seems some issue Marek found on testing. If fixed then I will try to > pick this > > patch series up. > > Marek has successfully tested v16. > > Could you please apply v16? > I am planning to merge this patch series soon, but I will be proceeding with the pull-request next week. As the DSIM driver is being moved to the bridge folder, I would like to wait for acknowledgment from the bridge maintainers. However, if there are no further comments until next week, I will proceed with the pull-request. Thanks, Inki Dae > Thanks >
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one fixup series to restore proper bridge chain order of Exynos Display pipeline. This is also required by a patch series[1] which makes existing Exynos DSI driver to be common driver so that it can be used by Exynos and I.MX8MM SoC commonly - under the review yet. [1] https://lore.kernel.org/linux-arm-kernel/d4267645-448c-f702-fcc3-6c534d9ec...@denx.de/T/ Please let me know if there is any problem. Thanks, Inki Dae The following changes since commit 68de345e101ce9a24e5c8849e69dd0dba2e8c9b2: Merge tag 'drm-misc-next-2023-01-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-01-25 12:14:08 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.3 for you to fetch changes up to 1a1ce789e6c5da5a16d3d17bc228c6ab0b5863ed: drm: exynos: dsi: Restore proper bridge chain order (2023-01-26 15:11:24 +0900) One fixup series - Make sure to restore bridge chain order by enabling the drm panel prepare_prev_first flag of the bridge and panel drivers - tc358764 display bridge device and Samsung s6e3ha2/s6e63j0x03/s6e8aa0 panel devices. In case of any boards using Exynos5433 SoC, below Display pipeline could be configured. Decon -> MIC -> MIPI-DSI -> Panel So, this patch series makes sure to enable previous bridge device before enabling MIPI-DSI device. Jagan Teki (2): drm: panel: Enable prepare_prev_first flag for samsung-s6e panels drm: exynos: dsi: Restore proper bridge chain order Marek Szyprowski (1): drm/bridge: tc358764: Enable pre_enable_prev_first flag drivers/gpu/drm/bridge/tc358764.c| 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +++-- drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 + drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 + drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 + 5 files changed, 11 insertions(+), 2 deletions(-)
Re: [PATCH 09/26] drm: exynos: Remove #ifdef guards for PM related functions
Hi,
2022년 11월 8일 (화) 오전 2:52, Paul Cercueil 님이 작성:
>
> Use the DEFINE_RUNTIME_DEV_PM_OPS(), SYSTEM_SLEEP_PM_OPS(),
> RUNTIME_PM_OPS() and pm_ptr() macros to handle the runtime and suspend
> PM callbacks.
>
> These macros allow the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_PM is disabled, without having
> to use #ifdef guards.
>
> This has the advantage of always compiling these functions in,
> independently of any Kconfig option. Thanks to that, bugs and other
> regressions are subsequently easier to catch.
>
> Signed-off-by: Paul Cercueil
Acked-by : Inki Dae
Thanks for cleanup,
Inki Dae
> ---
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Krzysztof Kozlowski
> Cc: Alim Akhtar
> Cc: Jingoo Han
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_dp.c| 11 +++
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +++---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 12 +++-
> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++-
> 9 files changed, 28 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 8155d7e650f1..2867b39fa35e 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -710,7 +710,6 @@ static irqreturn_t decon_irq_handler(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> -#ifdef CONFIG_PM
> static int exynos5433_decon_suspend(struct device *dev)
> {
> struct decon_context *ctx = dev_get_drvdata(dev);
> @@ -741,14 +740,10 @@ static int exynos5433_decon_resume(struct device *dev)
>
> return ret;
> }
> -#endif
>
> -static const struct dev_pm_ops exynos5433_decon_pm_ops = {
> - SET_RUNTIME_PM_OPS(exynos5433_decon_suspend, exynos5433_decon_resume,
> - NULL)
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> -pm_runtime_force_resume)
> -};
> +static DEFINE_RUNTIME_DEV_PM_OPS(exynos5433_decon_pm_ops,
> +exynos5433_decon_suspend,
> +exynos5433_decon_resume, NULL);
>
> static const struct of_device_id exynos5433_decon_driver_dt_match[] = {
> {
> @@ -881,7 +876,7 @@ struct platform_driver exynos5433_decon_driver = {
> .remove = exynos5433_decon_remove,
> .driver = {
> .name = "exynos5433-decon",
> - .pm = _decon_pm_ops,
> + .pm = pm_ptr(_decon_pm_ops),
> .of_match_table = exynos5433_decon_driver_dt_match,
> },
> };
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7080cf7952ec..3126f735dedc 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -779,7 +779,6 @@ static int decon_remove(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> static int exynos7_decon_suspend(struct device *dev)
> {
> struct decon_context *ctx = dev_get_drvdata(dev);
> @@ -836,21 +835,16 @@ static int exynos7_decon_resume(struct device *dev)
> err_pclk_enable:
> return ret;
> }
> -#endif
>
> -static const struct dev_pm_ops exynos7_decon_pm_ops = {
> - SET_RUNTIME_PM_OPS(exynos7_decon_suspend, exynos7_decon_resume,
> - NULL)
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> -};
> +static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
> +exynos7_decon_resume, NULL);
>
> struct platform_driver decon_driver = {
> .probe = decon_probe,
> .remove = decon_remove,
> .driver = {
> .name = "exynos-decon",
> - .pm = _decon_pm_ops,
> + .pm = pm_ptr(_decon_pm_ops),
> .of_match_table = decon_driver_dt_match,
> },
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
&g
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Sorry for late. Just one cleanup and fixup which corrects return type. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 320305923c88258ce50c75bf721e9bf2e420ab27: Merge tag 'du-next-20220907' of git://linuxtv.org/pinchartl/media into drm-next (2022-09-23 03:52:08 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.1 for you to fetch changes up to 1261255531088208daeca818e2b486030b5339e5: drm/exynos: Fix return type for mixer_mode_valid and hdmi_mode_valid (2022-09-26 10:13:00 +0900) Cleanup - Use drm_display_info.is_hdmi instead of drm_detect_hdmi_monitor() for efficiency. Fixup - Correct return type of mixer_mode_valid and hdmi_mode_valid functions. This was reported by Dan Carpenter, https://github.com/ClangBuiltLinux/linux/issues/1703 Nathan Huckleberry (1): drm/exynos: Fix return type for mixer_mode_valid and hdmi_mode_valid hongao (1): drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +++--- drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
Re: [PATCH] drm/exynos: fix repeated words in comments
Hi, 2022년 8월 23일 (화) 오후 10:37, Robin Murphy 님이 작성: > > On 2022-08-23 13:21, Jilin Yuan wrote: > > Delete the redundant word 'next'. > > From the context, I'm not sure it is redundant - as far as I can tell > this comment seems to be describing a sequence of 3 commands, where > "current" is the first, "next" is the second, and "next next" implies > the third. The whole comment could certainly be reworded more clearly, > but as it stands I suspect a replacement like s/next next/next+1/ is > more likely to be correct. > "next next" is correct. :) As you said, "next next" could be reworded more clearly. As of now, the original sentence could make it confusing. Thanks, Inki Dae > Robin. > > > Signed-off-by: Jilin Yuan > > --- > > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > index 471fd6c8135f..4f9edca66632 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > @@ -1195,7 +1195,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device > > *drm_dev, void *data, > >* If don't clear SFR registers, the cmdlist is affected by register > >* values of previous cmdlist. G2D hw executes SFR clear command and > >* a next command at the same time then the next command is ignored > > and > > - * is executed rightly from next next command, so needs a dummy > > command > > + * is executed rightly from next command, so needs a dummy command > >* to next command of SFR clear command. > >*/ > > cmdlist->data[cmdlist->last++] = G2D_SOFT_RESET;
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just two cleanups which remove invalid maintainer info and one fixup for releasing resouce. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit c6a3d73592ae20f2f6306f823aa5121c83c88223: Merge tag 'drm-intel-gt-next-2022-06-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-07-01 14:14:52 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.20 for you to fetch changes up to 48b927770f8ad3f8cf4a024a552abf272af9f592: drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed. (2022-07-12 13:56:54 +0900) Two cleanups - Remove Joonyoung Shim from MAINTAINERS and relevant yaml files. He left from Samsung so his email address isn't valid anymore. Fixup - Fix resume function issue of exynos decon driver by calling clk_disable_unprepare() properly if clk_prepare_enable() failed. Jian Zhang (1): drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed. Krzysztof Kozlowski (2): drm/exynos: MAINTAINERS: move Joonyoung Shim to credits dt-bindings: remove Joonyoung Shim from maintainers CREDITS | 4 .../display/samsung/samsung,exynos-hdmi-ddc.yaml| 1 - .../bindings/display/samsung/samsung,exynos-hdmi.yaml | 1 - .../bindings/display/samsung/samsung,exynos-mixer.yaml | 1 - .../display/samsung/samsung,exynos5433-decon.yaml | 1 - .../display/samsung/samsung,exynos5433-mic.yaml | 1 - .../bindings/display/samsung/samsung,exynos7-decon.yaml | 1 - .../bindings/display/samsung/samsung,fimd.yaml | 1 - .../bindings/phy/samsung,exynos-hdmi-phy.yaml | 1 - MAINTAINERS | 1 - drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 + 11 files changed, 17 insertions(+), 13 deletions(-)
Re: [PATCH] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
22. 6. 16. 16:22에 hongao 이(가) 쓴 글: > Once EDID is parsed, the monitor HDMI support information is available > through drm_display_info.is_hdmi. > > This driver calls drm_detect_hdmi_monitor() to receive the same > information, which is less efficient. > > Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi > instead. > Applied. Thanks, Inki Dae > Signed-off-by: hongao > --- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 7655142a4651..17e9f5efbcfc 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -893,7 +893,7 @@ static int hdmi_get_modes(struct drm_connector *connector) > if (!edid) > return -ENODEV; > > - hdata->dvi_mode = !drm_detect_hdmi_monitor(edid); > + hdata->dvi_mode = !connector->display_info.is_hdmi; > DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n", > (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"), > edid->width_cm, edid->height_cm);
Re: Exynos vblank timeout issue
Hi Martin, 2022년 6월 4일 (토) 오후 8:05, Martin Jücker 님이 작성: > > On Sat, Jun 04, 2022 at 01:05:39PM +0900, Inki Dae wrote: > > Hi Martin, > > > > Hi Inki, > > > What kind of panel does Galaxy Note 10.1 use? I guess it uses I80 > > panel which needs CPU-trigger. > > the Note 10.1 uses a Samsung LTL101AL01 LCD which is connected via the > RGB interface. > > In the meantime I tried several things but to no avail. Krzysztof > proposed in IRC to disable devfreq which had no effect. I compared the > mainline sources with the vendor kernel, but there are no notable > differences and the parts that were a bit different also didn't solve > the problem when applied to mainline. > > I then tried to reproduce the issue, I noticed that things go wrong as > soon as I get to planes that are less than 8x8 pixels. There is two > different issues I can make out: > > 1) Active pixels are not what expected, so the plane is 1x4 pixels but > only two pixels will be visible on the display > 2) The screen goes dark and the vblank interrupt stops working Seems malfunctioning of display controller, FIMD device. > > The vblank occurs for all planes that are 1x8 or any multiple of it, so > 1x16, 1x24 as well as planes bigger than 1x279 in size. This is for the > primary plane. A width of two seems to be fine here. FIMD device has a limit to DMA burst size. Please see how burst size is set according to pixel format, https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/tree/drivers/gpu/drm/exynos/exynos_drm_fimd.c?h=exynos-drm-fixes#n660 I think Android platform uses XRGB888 or ARGB888 for framebuffer. In this case, the burst size - it means the minimum size that FIMD's DMA controller reads some portion of frame buffer from memory - is 16 words. So width size should be multiple of the word size. Could you align the width size of the frame buffer to multiple of 16? According to your analysis, multiple of 8 would be ok. Thanks, Inki Dae > > For overlay planes, the situation is worse. All planes of width one will > trigger a vsync timeout. Also, planes of widths smaller 8 seem to be hit > and miss, most of them don't work. > > The first issue with the wrong number of pixels seems to be for small > planes less than 8x8 pixels that don't trigger the vsync issue but it's > more difficult to find a pattern here. It looks like even numbers like > 4x4, 4x6 are fine but as soon as at least one odd number is present, it > will go down the drain. 5x6 for example will only display 5x5 pixels, > 5x5 will display four rows of five pixels and one row with one pixel. > > Kind Regards > Martin > > > > > If so, you may need to check if the panel device works correctly after > > booting because FIMD will incur vsync timeout if the panel doesn't > > work. > > I think you could try to check if te signal works or not in > > exynos_dsi_te_irq_handler function of exynos_drm_dsi.c > > > > Thanks, > > Inki Dae > > > > 2022년 5월 27일 (금) 오전 8:34, Martin Jücker 님이 작성: > > > > > > Hello again, > > > > > > I tried to dig around a bit to unearth some more information. What I'm > > > seeing is that it works just fine in the beginning, planes are updated a > > > couple of times and suddenly, after one of the plane updates, the > > > interrupt handler in the FIMD driver is no longer called. The screen > > > goes dark but the device is still operational, e.g. ADB works fine, I > > > can connect and execute commands. > > > > > > Trying to figure out what is called when and curious about the state of > > > the registers, I littered the code with print statements and it looks > > > like vsync is still active, no other code calls into disabling it. All > > > registers are as expected, e.g. VIDINTCON0 has the interrupt bit set. I > > > also had a look at the interrupt combiner, this too has the > > > corresponding lcd0-1 interrupt enabled at all times and there is no > > > interrupt pending, even after FIMD stopped receiving them. > > > > > > Looking at the wiki at https://exynos.wiki.kernel.org/todo_tasks I found > > > issue #9. It's about trashed display or DMA freeze if planes are too > > > narrow and I was wondering if this could be related. So I had a look at > > > the drm debug output and planes are indeed getting very small. This > > > happens exactly when the animation that is triggering the issue is > > > playing, so this would match. Looking a bit closer at the position and > > > size of the planes, I could see that the last working vsync was right > > > after one of the planes was exactly 1 pixel in widt
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just two regression fixups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3: Linux 5.19-rc2 (2022-06-12 16:11:37 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-v5.19-rc3 for you to fetch changes up to 7d787184a18f0f84e996de8ff007e4395c1978ea: drm/exynos: mic: Rework initialization (2022-06-14 22:32:16 +0900) two regression fixups - Check a null pointer instead of IS_ERR(). - Rework initialization code of Exynos MIC driver. Dan Carpenter (1): drm/exynos: fix IS_ERR() vs NULL check in probe Marek Szyprowski (1): drm/exynos: mic: Rework initialization drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 ++--- drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 ++--- 2 files changed, 15 insertions(+), 33 deletions(-)
Re: Exynos vblank timeout issue
Hi Martin, What kind of panel does Galaxy Note 10.1 use? I guess it uses I80 panel which needs CPU-trigger. If so, you may need to check if the panel device works correctly after booting because FIMD will incur vsync timeout if the panel doesn't work. I think you could try to check if te signal works or not in exynos_dsi_te_irq_handler function of exynos_drm_dsi.c Thanks, Inki Dae 2022년 5월 27일 (금) 오전 8:34, Martin Jücker 님이 작성: > > Hello again, > > I tried to dig around a bit to unearth some more information. What I'm > seeing is that it works just fine in the beginning, planes are updated a > couple of times and suddenly, after one of the plane updates, the > interrupt handler in the FIMD driver is no longer called. The screen > goes dark but the device is still operational, e.g. ADB works fine, I > can connect and execute commands. > > Trying to figure out what is called when and curious about the state of > the registers, I littered the code with print statements and it looks > like vsync is still active, no other code calls into disabling it. All > registers are as expected, e.g. VIDINTCON0 has the interrupt bit set. I > also had a look at the interrupt combiner, this too has the > corresponding lcd0-1 interrupt enabled at all times and there is no > interrupt pending, even after FIMD stopped receiving them. > > Looking at the wiki at https://exynos.wiki.kernel.org/todo_tasks I found > issue #9. It's about trashed display or DMA freeze if planes are too > narrow and I was wondering if this could be related. So I had a look at > the drm debug output and planes are indeed getting very small. This > happens exactly when the animation that is triggering the issue is > playing, so this would match. Looking a bit closer at the position and > size of the planes, I could see that the last working vsync was right > after one of the planes was exactly 1 pixel in width and vsync only > stopped working one update later. Here are the plane updates from the > logs: > > - > > Planes getting smaller and smaller with each update: > plane : offset_x/y(0,0), width/height(4,800) > plane : offset_x/y(4,0), width/height(1276,800) > plane : offset_x/y(0,0), width/height(1280,800) > plane : offset_x/y(0,776), width/height(1280,24) > > plane : offset_x/y(0,0), width/height(2,800) > plane : offset_x/y(2,0), width/height(1278,800) > plane : offset_x/y(0,0), width/height(1280,800) > plane : offset_x/y(0,776), width/height(1280,24) > > plane : offset_x/y(0,0), width/height(1,800) > plane : offset_x/y(1,0), width/height(1279,800) > plane : offset_x/y(0,0), width/height(1280,800) > plane : offset_x/y(0,776), width/height(1280,24) > > Still got a vsync in between those two. But after the following update, > it's dead: > plane : offset_x/y(0,0), width/height(1280,800) > plane : offset_x/y(0,0), width/height(1280,24) > plane : offset_x/y(0,740), width/height(1280,60) > plane : offset_x/y(0,0), width/height(1280,800) > > -> vsync timeout comes here > > - > > I have no idea how to analyze this further on the kernel side. I'll try > to write an executable that triggers this bug next. If you have any > ideas on that, I'd be very grateful. > > Kind Regards > Martin > > On Sun, May 22, 2022 at 12:06:39PM +0200, Martin Jücker wrote: > > On Sun, May 22, 2022 at 09:45:51AM +0200, Krzysztof Kozlowski wrote: > > > On 22/05/2022 02:02, Martin Jücker wrote: > > > > Hello, > > > > > > > > I'm trying to get Android 12 up and running on my Galaxy Note 10.1 which > > > > is based on Exynos 4412 with a Mali GPU. For Android 11, I had no issues > > > > with graphics but after upgrading and building Android 12, I'm getting a > > > > vblank wait timeout shortly after starting the device setup, which in > > > > turn leads to my display turning black and SurfaceFlinger hanging. This > > > > can be reliably reproduced after every reboot, so much so that it's > > > > basically always on the exact same step of the setup. > > > > > > > > I'm using the following setup: > > > > > > > > * 5.10.101 Android Common Kernel with some patches to get > > > > the Note 10.1 up and running > > > > > > It's Android kernel, so not upstream. It is perfectly fine to use > > > downstream kernels, but with the issues you also go to downstream folks. > > > I have no clue what Android did to Exynos. > > > > Hi Krzysztof, > > > > indeed, that was my mistake. Should have done that on mainline first. > > > > I rebased some patches on top of v5.17.9 and tried again, same result. > > There are no Android patches in there, o
Re: [PATCH] drm/exynos: mic: Rework initialization
Hi Marek,
22. 5. 13. 17:31에 Marek Szyprowski 이(가) 쓴 글:
> Commit dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
> moved Exynos MIC attaching from DSI to MIC driver. However the method
> proposed there is incomplete and cannot really work. To properly attach
> it to the bridge chain, access to the respective encoder is needed. The
> Exynos MIC driver always attaches to the encoder created by the Exynos
> DSI driver, so grab it via available helpers for getting access to the
> CRTC and encoders. This also requires to change the order of driver
> component binding to let DSI to be bound before MIC.
>
> Fixes: dd8b6803bc49 ("exynos: drm: 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
> really produces valid display, I only checked if it boots and reports
> valid DRM structures to the userspace.
>
> If possible, please merge this to the drm-misc-next together with the
> rest of Exynos DSI to drm bridge rework patches.
The commit-id, dd8b6803bc49, has already been merged to drm-next. Seems no need
to go drm-misc-next.
So I will merge it as a regression fix after the review, which will be merged
to 5.19-rc series.
Please let me know if there is my missing something.
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 ++--
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 +++--
> 2 files changed, 15 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 424ea23eec32..16c539657f73 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -176,15 +176,15 @@ static struct exynos_drm_driver_info
> exynos_drm_drivers[] = {
> }, {
> DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
> DRM_COMPONENT_DRIVER
> - }, {
> - DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> - DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
> DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
> DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
> DRM_COMPONENT_DRIVER
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 9e06f8e2a863..09ce28ee08d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -26,6 +26,7 @@
> #include
>
> #include "exynos_drm_drv.h"
> +#include "exynos_drm_crtc.h"
>
> /* Sysreg registers for MIC */
> #define DSD_CFG_MUX 0x1004
> @@ -100,9 +101,7 @@ struct exynos_mic {
>
> bool i80_mode;
> struct videomode vm;
> - struct drm_encoder *encoder;
> struct drm_bridge bridge;
> - struct drm_bridge *next_bridge;
>
> bool enabled;
> };
> @@ -229,8 +228,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool
> enable)
> writel(reg, mic->reg + MIC_OP);
> }
>
> -static void mic_disable(struct drm_bridge *bridge) { }
> -
> static void mic_post_disable(struct drm_bridge *bridge)
> {
> struct exynos_mic *mic = bridge->driver_private;
> @@ -297,34 +294,30 @@ static void mic_pre_enable(struct drm_bridge *bridge)
> mutex_unlock(_mutex);
> }
>
> -static void mic_enable(struct drm_bridge *bridge) { }
> -
> -static int mic_attach(struct drm_bridge *bridge,
> - enum drm_bridge_attach_flags flags)
> -{
> - struct exynos_mic *mic = bridge->driver_private;
> -
> - return drm_bridge_attach(bridge->encoder, mic->next_bridge,
> - >bridge, flags);
> -}
> -
> static const struct drm_bridge_funcs mic_bridge_funcs = {
> - .disable = mic_disable,
> .post_disable = mic_post_disable,
> .mode_set = mic_mode_set,
> .pre_enable = mic_pre_enable,
> - .enable = mic_enable,
> - .attach = mic_attach,
> };
>
> static int exynos_mic_bind(struct device *dev, struct device *master,
> void *data)
> {
> struct exynos_mic *mic = dev_get_drvdata(dev);
> + struct drm_device *drm_dev = data;
> +
Re: [PATCH] drm/exynos: fix IS_ERR() vs NULL check in probe
Hi,
22. 4. 12. 13:19에 Dan Carpenter 이(가) 쓴 글:
> On Tue, Apr 12, 2022 at 10:01:20AM +0900, Inki Dae wrote:
>> Hi Dan Carpenter.
>>
>> Same patch[1] was posted so I will pick it up.
>>
>> [1]
>> https://protect2.fireeye.com/v1/url?k=94e9d569-f562c05f-94e85e26-000babff9b5d-4d4f5b20cfffa24c=1=727c2c54-2082-4e0f-87d7-c6702bf4c81e=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg967488.html
>>
>>
>
> It's not the same. That one returns -EINVAL and mine returns
> -EPROBE_DEFER. I obvoiously thought that -EPROBE_DEFER was the correct
> return but I wasn't positive. -EPROBE_DEFER is kind of a special
> return so I think it matters to get this correct.
>
Correct so I requested[1] him to fix it but the delivery failed. :( I will just
pick your patch up. :)
[Delivery Failure] Re: [PATCH -next] drm/exynos: mic: fix return value check in
exynos_mic_probe().
[1] My email sent below,
22. 4. 6. 18:22에 Yang Yingliang 이(가) 쓴 글:
> If of_graph_get_remote_node() fails, it returns NULL pointer, replaces
> IS_ERR() check with NULL pointer check.
>
> Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 9e06f8e2a863..43fc357a6682 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -434,9 +434,9 @@ static int exynos_mic_probe(struct platform_device *pdev)
>
> remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> mic->next_bridge = of_drm_find_bridge(remote);
> - if (IS_ERR(mic->next_bridge)) {
> + if (!mic->next_bridge) {
> DRM_DEV_ERROR(dev, "mic: Failed to find next bridge\n");
> - ret = PTR_ERR(mic->next_bridge);
> + ret = -EINVAL;
-EPROBE_DEFER should be returned instead. Could you modify and resend it again?
> regards,
> dan carpenter
>
>
Re: [PATCH] drm/exynos: fix IS_ERR() vs NULL check in probe
Hi Dan Carpenter.
Same patch[1] was posted so I will pick it up.
[1] https://www.spinics.net/lists/arm-kernel/msg967488.html
Thanks,
Inki Dae
22. 4. 8. 19:21에 Dan Carpenter 이(가) 쓴 글:
> The of_drm_find_bridge() does not return error pointers, it returns
> NULL on error.
>
> Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
> Signed-off-by: Dan Carpenter
> ---
> -EPROBE_DEFER is the correct return, right?
>
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 9e06f8e2a863..07e04ceb2476 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -434,9 +434,9 @@ static int exynos_mic_probe(struct platform_device *pdev)
>
> remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> mic->next_bridge = of_drm_find_bridge(remote);
> - if (IS_ERR(mic->next_bridge)) {
> + if (!mic->next_bridge) {
> DRM_DEV_ERROR(dev, "mic: Failed to find next bridge\n");
> - ret = PTR_ERR(mic->next_bridge);
> + ret = -EPROBE_DEFER;
> goto err;
> }
>
[GIT PULL] exynos-drm-next for v5.18
Hi Dave and Daniel, Just adding BGR pixel format support per a plane. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit fedc89821990013608bc210c9aef5bb33a1345a7: drm/exynos: Search for TE-gpio in DSI panel's node (2022-03-04 17:13:51 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-v5.18 for you to fetch changes up to 2d684f4e155c1e80ff63bd503930171c460eac5b: drm/exynos: fimd: add BGR support for exynos4/5 (2022-03-04 17:13:52 +0900) New feature - Add BGR pixel format support for FIMD device. As for this, this patch uses undocumented register, WIN_RGB_ORDER, but it is safe because product kernels have been using same register. Martin Jücker (1): drm/exynos: fimd: add BGR support for exynos4/5 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++-- include/video/samsung_fimd.h | 4 +++ 2 files changed, 44 insertions(+), 2 deletions(-)
Re: [PATCH v3 RESEND 21/24] drm/exynos/decon5433: add local path support
Hi Krzysztof,
22. 2. 7. 01:51에 Krzysztof Kozlowski 이(가) 쓴 글:
> On 25/03/2019 08:13, Andrzej Hajda wrote:
>> GSCALERs in Exynos5433 have local path to DECON and DECON_TV.
>> They can be used as extra planes with support for non-RGB formats and
>> scaling.
>> To enable it on DECON update_plane and disable_plane callback should
>> be modified. Moreover DSD mux should be set accordingly, and finally
>> atomic_check callback should be used to limit the number of active planes.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 80 +++
>> drivers/gpu/drm/exynos/regs-decon5433.h | 6 ++
>> 2 files changed, 72 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ex
> Hi guys!
>
> I am working on DRM bindings conversion to DT schema format and I found
> this set only partially applied. I merged the DTS patches ("dsd" clock),
> but I think the driver and bindings were not picked up.
>
> Nevertheless I am going to include the "dsd" clock in the new bindings,
> so the DTS passes DT schema checks. Let me know if other approach
> (revert of DTS change) should be taken.
>
Sorry for late response.
As of now, "dsd" is a dead property not used anywhere.
This patch series makes real user not to work correctly due to ABI change.
How about reverting it until this patch series is merged after fixing the real
user problem?
Thanks,
Inki Dae
> Best regards,
> Krzysztof
>
Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5
Hi Martin, 22. 2. 25. 18:33에 Martin Jücker 이(가) 쓴 글: > Hello Inki, > > On Fri, Feb 25, 2022 at 12:52:56PM +0900, Inki Dae wrote: >> Hi Martin, >> >> 22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글: >>> Hello Inki, >>> >>> On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote: >>>> Hi Martin. >>>> >>>> I found that exynos4 and 5 data sheet include documented same register. >>>> RGB_ORDER_E field of VIDCONx registers will do same thing. >>> >>> If I read the manual correctly, this register combined with the >>> RGB_ORDER_O makes it possible to map the whole RGB interface output to a >>> different order. What my patch provides is a way to configure each >>> hardware plane separately while maintaining a consistent output on the >>> RGB interface. >>> >> >> Understood. Your patch will allow BGR pixel order per a plane. Seems to be >> useful because a framebuffer with BGR pixel format can be displayed on >> screen without any color space conversion. :) >> >>> Implementing the RGB_ORDER_O and E would need some logic to make sure >>> that all planes are always using the same RGB order. >>> >>>> >>>> I'm not sure whether the use of undocumented register is safe or not - >>>> maybe some HW bug exists. >>> >>> I see, that makes sense. Would it be possible then to introduce a new >>> compatible, e.g. samsung,exynos4210-fimd-ext which can be used on tested >> >> Seems providing a new compatible is not a good idea. >> >>> devices? I know that some other Galaxy Note and S devices with the >>> exynos4 chip have the same problem (and solution). >> >> Could you give me more details about the same problem and its solution on >> the devices? >> It would be useful for us to decide the upstream direction. >> >> If necessary then we may need to contact HW engineer for clarity. > > Here is my current understanding of the situation: > > The issue is related to Android and a recovery image having conflicting > pixel formats on the same device. There is a solution in Replicant[1] > for this using parameters for the fimd driver to force the pixel format > to RGB or BGR. It's using the PNRMODE register on VIDCON0, but this > solution needs two separate kernels to be built to add the parameter as > the boot loader is not adjustable. > > This was also discussed in dri-devel irc and it was proposed to expose > both formats and fail the atomic commit if userspace tried to use both > RGB and BGR formats at the same time. With this approach there should be > something on the screen but it might happen that some users can't deal > with the failing commits as it's rather difficult to find the cause and > fix it on the go. Thanks for sharing. > > After that I accidentally discovered this undocumented register while > reading the old vendor sources and it seems that it fixes all the Are the old vendor sources using this undocumented register? If so then the use of the register would be safe. > issues. At least if there are no HW bugs as you mentioned. I will try to contact HW engineer and check if no problem. Thanks, Inki Dae > > Kind Regards > Martin > > [1] > https://protect2.fireeye.com/v1/url?k=d515db34-b4683348-d514507b-74fe485cc33c-0ee001ffdcafd932=1=851ccfed-b6fa-4794-8989-27ef28bc7ac6=https%3A%2F%2Fgit.replicant.us%2Freplicant-next%2Fkernel_replicant_linux%2Fcommit%2F%3Fh%3Dreplicant-11%26id%3Dcc5a0615b40cd5ede1eb87a60daa50333701a135 > >> >> Thanks, >> Inki Dae >> >>> >>>> >>>> Anyway, I'd like to recommend you to use documented register only. >>>> >>>> Sorry for late and thanks, >>>> Inki Dae >>> >>> Kind Regards >>> Martin >>> >>>> >>>> 22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글: >>>>> In the downstream kernels for exynos4 and exynos5 devices, there is an >>>>> undocumented register that controls the order of the RGB output. It can >>>>> be set to either normal order or reversed, which enables BGR support for >>>>> those SoCs. >>>>> >>>>> This patch enables the BGR support for all the SoCs that were found to >>>>> have at least one device with this logic in the corresponding downstream >>>>> kernels. >>>>> >>>>> Signed-off-by: Martin Jücker >>>>> --- >>>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++-- >>>>> include/
Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5
Hi Martin,
22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글:
> Hello Inki,
>
> On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote:
>> Hi Martin.
>>
>> I found that exynos4 and 5 data sheet include documented same register.
>> RGB_ORDER_E field of VIDCONx registers will do same thing.
>
> If I read the manual correctly, this register combined with the
> RGB_ORDER_O makes it possible to map the whole RGB interface output to a
> different order. What my patch provides is a way to configure each
> hardware plane separately while maintaining a consistent output on the
> RGB interface.
>
Understood. Your patch will allow BGR pixel order per a plane. Seems to be
useful because a framebuffer with BGR pixel format can be displayed on screen
without any color space conversion. :)
> Implementing the RGB_ORDER_O and E would need some logic to make sure
> that all planes are always using the same RGB order.
>
>>
>> I'm not sure whether the use of undocumented register is safe or not - maybe
>> some HW bug exists.
>
> I see, that makes sense. Would it be possible then to introduce a new
> compatible, e.g. samsung,exynos4210-fimd-ext which can be used on tested
Seems providing a new compatible is not a good idea.
> devices? I know that some other Galaxy Note and S devices with the
> exynos4 chip have the same problem (and solution).
Could you give me more details about the same problem and its solution on the
devices?
It would be useful for us to decide the upstream direction.
If necessary then we may need to contact HW engineer for clarity.
Thanks,
Inki Dae
>
>>
>> Anyway, I'd like to recommend you to use documented register only.
>>
>> Sorry for late and thanks,
>> Inki Dae
>
> Kind Regards
> Martin
>
>>
>> 22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
>>> In the downstream kernels for exynos4 and exynos5 devices, there is an
>>> undocumented register that controls the order of the RGB output. It can
>>> be set to either normal order or reversed, which enables BGR support for
>>> those SoCs.
>>>
>>> This patch enables the BGR support for all the SoCs that were found to
>>> have at least one device with this logic in the corresponding downstream
>>> kernels.
>>>
>>> Signed-off-by: Martin Jücker
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
>>> include/video/samsung_fimd.h | 4 +++
>>> 2 files changed, 44 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index c735e53939d8..cb632360c968 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -109,6 +109,7 @@ struct fimd_driver_data {
>>> unsigned int has_dp_clk:1;
>>> unsigned int has_hw_trigger:1;
>>> unsigned int has_trigger_per_te:1;
>>> + unsigned int has_bgr_support:1;
>>> };
>>>
>>> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data
>>> = {
>>> .lcdblk_bypass_shift = 1,
>>> .has_shadowcon = 1,
>>> .has_vtsel = 1,
>>> + .has_bgr_support = 1,
>>> };
>>>
>>> static struct fimd_driver_data exynos5_fimd_driver_data = {
>>> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data
>>> = {
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_dp_clk = 1,
>>> + .has_bgr_support = 1,
>>> };
>>>
>>> static struct fimd_driver_data exynos5420_fimd_driver_data = {
>>> @@ -162,6 +165,7 @@ static struct fimd_driver_data
>>> exynos5420_fimd_driver_data = {
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> + .has_bgr_support = 1,
>>> };
>>>
>>> struct fimd_context {
>>> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
>>> DRM_FORMAT_ARGB,
>>> };
>>>
>>> +static const uint32_t fimd_extended_formats[] = {
>>> + DRM_FORMAT_C8,
>>> + DRM_FORMAT_XRGB1555,
>>> + DRM_FORMAT_XBGR1555,
>>> + DRM_FORMAT_RGB565,
>>> + DRM_FORMAT_BGR565,
>>> + DRM_FORMAT_XRGB,
>>> + DRM_FORMAT_XBGR,
>>> + DRM_FORMAT_ARGB,
>>> + DRM_FORMAT_ABGR,
>>> +};
&
[GIT PULL] exynos-drm-fixes for rc6
Hi Dave and Daniel, Just fixups series. Ps. my previous git-pull request[1] isn't merged so I'm sending it again after rebasing on top of drm-fixes. Please kindly let me know if there is any problem. Thanks, Inki Dae [1] https://www.spinics.net/lists/dri-devel/msg333237.html The following changes since commit ecf8a99f4807c17fa310a83067a95964cedd9ac1: Merge tag 'drm-intel-fixes-2022-02-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-02-25 05:51:04 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-v5.17-rc6 for you to fetch changes up to 4188db23285e28d9e9b9096f856cdcd7868005ee: drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-25 09:50:48 +0900) Fixups - Make display controller drivers for Exynos series to use platform_get_irq and platform_get_irq_byname functions to get the interrupt, which prevents irq chaning from messed up when using hierarchical interrupt domains which use "interrupts" property in the node. - Fix two regressions to TE-gpio handling. Lad Prabhakar (5): drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the interrupt drm/exynos: mixer: Use platform_get_irq() to get the interrupt drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the interrupt drm/exynos/fimc: Use platform_get_irq() to get the interrupt drm/exynos: gsc: Use platform_get_irq() to get the interrupt Marek Szyprowski (2): drm/exynos: Don't fail if no TE-gpio is defined for DSI driver drm/exynos: Search for TE-gpio in DSI panel's node drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 -- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 - drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++--- drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++ 6 files changed, 25 insertions(+), 43 deletions(-)
Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5
Hi Martin.
I found that exynos4 and 5 data sheet include documented same register.
RGB_ORDER_E field of VIDCONx registers will do same thing.
I'm not sure whether the use of undocumented register is safe or not - maybe
some HW bug exists.
Anyway, I'd like to recommend you to use documented register only.
Sorry for late and thanks,
Inki Dae
22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
> In the downstream kernels for exynos4 and exynos5 devices, there is an
> undocumented register that controls the order of the RGB output. It can
> be set to either normal order or reversed, which enables BGR support for
> those SoCs.
>
> This patch enables the BGR support for all the SoCs that were found to
> have at least one device with this logic in the corresponding downstream
> kernels.
>
> Signed-off-by: Martin Jücker
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
> include/video/samsung_fimd.h | 4 +++
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c735e53939d8..cb632360c968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,6 +109,7 @@ struct fimd_driver_data {
> unsigned int has_dp_clk:1;
> unsigned int has_hw_trigger:1;
> unsigned int has_trigger_per_te:1;
> + unsigned int has_bgr_support:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data =
> {
> .lcdblk_bypass_shift = 1,
> .has_shadowcon = 1,
> .has_vtsel = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data =
> {
> .has_vidoutcon = 1,
> .has_vtsel = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5420_fimd_driver_data = {
> @@ -162,6 +165,7 @@ static struct fimd_driver_data
> exynos5420_fimd_driver_data = {
> .has_vtsel = 1,
> .has_mic_bypass = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> struct fimd_context {
> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> +static const uint32_t fimd_extended_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> +};
> +
> static const unsigned int capabilities[WINDOWS_NR] = {
> 0,
> EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
> @@ -673,21 +689,25 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> val |= WINCONx_BYTSWP;
> break;
> case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XBGR1555:
> val |= WINCON0_BPPMODE_16BPP_1555;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> val |= WINCON0_BPPMODE_16BPP_565;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> val |= WINCON0_BPPMODE_24BPP_888;
> val |= WINCONx_WSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> default:
> val |= WINCON1_BPPMODE_25BPP_A1888;
> val |= WINCONx_WSWP;
> @@ -695,6 +715,18 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> + switch (pixel_format) {
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR565:
> + writel(WIN_RGB_ORDER_REVERSE, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + default:
> + writel(WIN_RGB_ORDER_FORWARD, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + }
> +
> /*
>* Setting dma-burst to 16Word causes permanent tearing for very small
>* buffers, e.g. cursor buffer. Burst Mode switching which based on
> @@ -1074,8 +1106,14 @@ static int
Re: [GIT PULL] exynos-drm-fixes
Hi Dave, Seems you missed. Is there any issue? Thanks, Inki Dae 22. 2. 10. 20:07에 Inki Dae 이(가) 쓴 글: > Hi Dave and Daniel, > >Just two fixup series - one is to fix irq chaining issue and other is >regressions to TE-gpio handling. > > Please let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit dfd42facf1e4ada021b939b4e19c935dcdd55566: > > Linux 5.17-rc3 (2022-02-06 12:20:50 -0800) > > are available in the Git repository at: > > gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos > tags/exynos-drm-fixes-for-v5.17-rc4 > > for you to fetch changes up to 38103fa72e0b70e3067fed489f8316dc5998f26c: > > drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-10 19:17:22 > +0900) > > > Fixups > - Make display controller drivers for Exynos series to use platform_get_irq > and platform_get_irq_byname functions to get the interrupt, which prevents > irq chaining from messed up when using hierarchical interrupt domains > which use "interrupts" property in the node. > - Fix two regressions to TE-gpio handling. > > > Lad Prabhakar (5): > drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the > interrupt > drm/exynos: mixer: Use platform_get_irq() to get the interrupt > drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the > interrupt > drm/exynos/fimc: Use platform_get_irq() to get the interrupt > drm/exynos: gsc: Use platform_get_irq() to get the interrupt > > Marek Szyprowski (2): > drm/exynos: Don't fail if no TE-gpio is defined for DSI driver > drm/exynos: Search for TE-gpio in DSI panel's node > > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++- > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 -- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 + > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 - > drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++--- > drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++ > 6 files changed, 25 insertions(+), 43 deletions(-) >
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just two fixup series - one is to fix irq chaining issue and other is regressions to TE-gpio handling. Please let me know if there is any problem. Thanks, Inki Dae The following changes since commit dfd42facf1e4ada021b939b4e19c935dcdd55566: Linux 5.17-rc3 (2022-02-06 12:20:50 -0800) are available in the Git repository at: gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v5.17-rc4 for you to fetch changes up to 38103fa72e0b70e3067fed489f8316dc5998f26c: drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-10 19:17:22 +0900) Fixups - Make display controller drivers for Exynos series to use platform_get_irq and platform_get_irq_byname functions to get the interrupt, which prevents irq chaining from messed up when using hierarchical interrupt domains which use "interrupts" property in the node. - Fix two regressions to TE-gpio handling. Lad Prabhakar (5): drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the interrupt drm/exynos: mixer: Use platform_get_irq() to get the interrupt drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the interrupt drm/exynos/fimc: Use platform_get_irq() to get the interrupt drm/exynos: gsc: Use platform_get_irq() to get the interrupt Marek Szyprowski (2): drm/exynos: Don't fail if no TE-gpio is defined for DSI driver drm/exynos: Search for TE-gpio in DSI panel's node drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 6 -- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 - drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++--- drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++ 6 files changed, 25 insertions(+), 43 deletions(-)
Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5
Hi Martin.
Thanks for your contribution,
Inki Dae
22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
> In the downstream kernels for exynos4 and exynos5 devices, there is an
> undocumented register that controls the order of the RGB output. It can
> be set to either normal order or reversed, which enables BGR support for
> those SoCs.
>
> This patch enables the BGR support for all the SoCs that were found to
> have at least one device with this logic in the corresponding downstream
> kernels.
>
> Signed-off-by: Martin Jücker
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
> include/video/samsung_fimd.h | 4 +++
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c735e53939d8..cb632360c968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,6 +109,7 @@ struct fimd_driver_data {
> unsigned int has_dp_clk:1;
> unsigned int has_hw_trigger:1;
> unsigned int has_trigger_per_te:1;
> + unsigned int has_bgr_support:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data =
> {
> .lcdblk_bypass_shift = 1,
> .has_shadowcon = 1,
> .has_vtsel = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data =
> {
> .has_vidoutcon = 1,
> .has_vtsel = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5420_fimd_driver_data = {
> @@ -162,6 +165,7 @@ static struct fimd_driver_data
> exynos5420_fimd_driver_data = {
> .has_vtsel = 1,
> .has_mic_bypass = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> struct fimd_context {
> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> +static const uint32_t fimd_extended_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> +};
> +
> static const unsigned int capabilities[WINDOWS_NR] = {
> 0,
> EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
> @@ -673,21 +689,25 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> val |= WINCONx_BYTSWP;
> break;
> case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XBGR1555:
> val |= WINCON0_BPPMODE_16BPP_1555;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> val |= WINCON0_BPPMODE_16BPP_565;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> val |= WINCON0_BPPMODE_24BPP_888;
> val |= WINCONx_WSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> default:
> val |= WINCON1_BPPMODE_25BPP_A1888;
> val |= WINCONx_WSWP;
> @@ -695,6 +715,18 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> + switch (pixel_format) {
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR565:
> + writel(WIN_RGB_ORDER_REVERSE, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + default:
> + writel(WIN_RGB_ORDER_FORWARD, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + }
> +
> /*
>* Setting dma-burst to 16Word causes permanent tearing for very small
>* buffers, e.g. cursor buffer. Burst Mode switching which based on
> @@ -1074,8 +1106,14 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> ctx->drm_dev = drm_dev;
>
> for (i = 0; i < WINDOWS_NR; i++) {
> - ctx->configs[i].pixel_formats = fimd_formats;
> - ctx->configs[i].num_pixel_f
Re: [PATCH] drm/exynos: Search for TE-gpio in DSI panel's node
Hi, 22. 1. 25. 00:22에 Henrik Grimler 이(가) 쓴 글: > Hi Marek, > > On Mon, Jan 24, 2022 at 02:52:46PM +0100, Marek Szyprowski wrote: >> TE-gpio, if defined, is placed in the panel's node, not the parent DSI >> node. Change the devm_gpiod_get_optional() to gpiod_get_optional() and >> pass proper device node to it. The code already has a proper cleanup >> path, so it looks that the devm_* variant has been applied assidentally > > Small observation: the spelling above should probably be"accidentally". > I can fix it. Thanks. >> during the conversion to gpiod API. > > Best regards, > Henrik Grimler >
Re: [PATCH] drm/exynos: Don't fail if no TE-gpio is defined for DSI driver
Hi Marek,
Thanks for fixing it.
Inki Dae.
22. 1. 21. 19:00에 Marek Szyprowski 이(가) 쓴 글:
> TE-gpio is optional and if it is not found then gpiod_get_optional()
> returns NULL. In such case the code will continue and try to convert NULL
> gpiod to irq what in turn fails. The failure is then propagated and driver
> is not registered.
>
> Fix this by returning early from exynos_dsi_register_te_irq() if no
> TE-gpio is found.
>
> Fixes: ee6c8b5afa62 ("drm/exynos: Replace legacy gpio interface for gpiod
> interface")
> Signed-off-by: Marek Szyprowski ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 32a36572b894..14ebbb124852 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1335,7 +1335,9 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
> *dsi,
> int te_gpio_irq;
>
> dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
> - if (IS_ERR(dsi->te_gpio)) {
> + if (!dsi->te_gpio) {
> + return 0;
> + } else if (IS_ERR(dsi->te_gpio)) {
> dev_err(dsi->dev, "gpio request failed with %ld\n",
> PTR_ERR(dsi->te_gpio));
> return PTR_ERR(dsi->te_gpio);
Re: [PATCH] Revert "drm: exynos: dsi: Convert to bridge driver"
Hi, 22. 1. 17. 오후 6:55에 Robert Foss 이(가) 쓴 글: > Hi Inki, > > On Fri, 14 Jan 2022 at 02:18, Inki Dae wrote: >> >> Hi Robert, >> >> 22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글: >>> Thank you again for catching this and submitting a revert. >>> >>> Reviewed-by: Robert Foss >> >>> Applied to drm-misc-next. >>> >> >> Trivial thing I think but just notice. With this applying - original patch >> set and revert one, merge conflict may happen on drm-next because >> drm-misc-next has this patch set exynos-drm-next tree doesn't include. >> Leaving this patch history in drm-misc-next is correct? > > Thanks for paying attention to this. > > If we end up seeing a conflict, the exynos patches can go in through drm-misc. > I mean is it correct to leave some patch set history - which is not reviewed and even not tested - exists in management tree? Anyway, it depends on maintainer of this tree. :) Thanks, Inki Dae
Re: [PATCH 0/5] drm/exynos: Use platform_get_irq*() variants to fetch IRQ's
Hi, 21. 12. 23. 오전 4:01에 Lad Prabhakar 이(가) 쓴 글: > Hi All, > > This patch series aims to drop using platform_get_resource() for IRQ types > in preparation for removal of static setup of IRQ resource from DT core > code. > > Dropping usage of platform_get_resource() was agreed based on > the discussion [0]. > > [0] https://patchwork.kernel.org/project/linux-renesas-soc/ > patch/20211209001056.29774-1-prabhakar.mahadev-lad...@bp.renesas.com/ > Applied. Thanks, Inki Dae > Cheers, > Prabhakar > > Lad Prabhakar (5): > drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the > interrupt > drm/exynos: mixer: Use platform_get_irq() to get the interrupt > drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the > interrupt > drm/exynos/fimc: Use platform_get_irq() to get the interrupt > drm/exynos: gsc: Use platform_get_irq() to get the interrupt > > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 + > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 - > drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++--- > drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++ > 5 files changed, 21 insertions(+), 41 deletions(-) >
Re: [PATCH 2/5] drm/exynos: mixer: Use platform_get_irq() to get the interrupt
Hi Lad Prabhakar,
21. 12. 23. 오전 4:01에 Lad Prabhakar 이(가) 쓴 글:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypassed the hierarchical setup and messed up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar
> ---
> Hi,
>
> Ideally I would expect the mixer_resources_init() to be called from probe
> instead from the bind callback. If platform_get_irq() returns -EPROBE_DEFER
> the bind callback will fail :(
If the bind callback failed then probe function of exynos drm driver will call
-EPROBE_DEFER like below so it must be no problem :),
in exynos_drm_platform_probe function
component_master_add_with_match()
in component_master_add_with_match function
try_to_bring_up_master()
Thanks,
Inki Dae
>
> Cheers,
> Prabhakar
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 41c54f1f60bc..e5204be86093 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -809,19 +809,17 @@ static int mixer_resources_init(struct mixer_context
> *mixer_ctx)
> return -ENXIO;
> }
>
> - res = platform_get_resource(mixer_ctx->pdev, IORESOURCE_IRQ, 0);
> - if (res == NULL) {
> - dev_err(dev, "get interrupt resource failed.\n");
> - return -ENXIO;
> - }
> + ret = platform_get_irq(mixer_ctx->pdev, 0);
> + if (ret < 0)
> + return ret;
> + mixer_ctx->irq = ret;
>
> - ret = devm_request_irq(dev, res->start, mixer_irq_handler,
> - 0, "drm_mixer", mixer_ctx);
> + ret = devm_request_irq(dev, mixer_ctx->irq, mixer_irq_handler,
> +0, "drm_mixer", mixer_ctx);
> if (ret) {
> dev_err(dev, "request interrupt failed.\n");
> return ret;
> }
> - mixer_ctx->irq = res->start;
>
> return 0;
> }
>
Re: [PATCH] Revert "drm: exynos: dsi: Convert to bridge driver"
Hi Robert, 22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글: > Thank you again for catching this and submitting a revert. > > Reviewed-by: Robert Foss > Applied to drm-misc-next. > Trivial thing I think but just notice. With this applying - original patch set and revert one, merge conflict may happen on drm-next because drm-misc-next has this patch set exynos-drm-next tree doesn't include. Leaving this patch history in drm-misc-next is correct? Thanks, Inki Dae
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just four cleanups such as replacing the use of legacy interface, implementing generic gem mmap, fixing a build warning and dropping unnecessary code. Please let me know if there is any problem. Thanks, Inki Dae The following changes since commit 1c405ca11bf563de1725e5ecfb4a74ee289d2ee9: Merge tag 'mediatek-drm-next-5.17' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next (2021-12-17 16:16:16 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.17 for you to fetch changes up to 760cceff996135fd4830f3d339446a04bd37ca0c: drm/exynos: drop the use of label from exynos_dsi_register_te_irq (2021-12-22 11:39:39 +0900) Four cleanups - Replacing lagacy gpio interface of dsi driver with gpiod one. - Implementing a generic GEM object mmap and use it instead of exynos specific one. - Dropping the use of label from dsi driver. Which also fixes a build warning. - Just trivial cleanup by dropping unnecessay code. Bernard Zhao (1): drm/exynos: remove useless type conversion Inki Dae (1): drm/exynos: drop the use of label from exynos_dsi_register_te_irq Maíra Canal (1): drm/exynos: Replace legacy gpio interface for gpiod interface Thomas Zimmermann (1): drm/exynos: Implement mmap as GEM object function drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 ++-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 49 +++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++--- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 4 +-- drivers/gpu/drm/exynos/exynos_drm_gem.c | 43 ++- drivers/gpu/drm/exynos/exynos_drm_gem.h | 5 6 files changed, 32 insertions(+), 102 deletions(-)
[PATCH] drm/exynos: drop the use of label from exynos_dsi_register_te_irq
Dropped the use of 'out' label from exynos_dsi_register_te_irq function
because the label isn't needed. This patch returns an error in each
error case directly not going to 'out' label.
With this patch build warning[1] is also fixed, which was reported by
kernel test robot
[1] https://www.spinics.net/lists/dri-devel/msg323803.html
Reported-by: kernel test robot
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b0b1acb7e712..32a36572b894 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1338,7 +1338,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi,
if (IS_ERR(dsi->te_gpio)) {
dev_err(dsi->dev, "gpio request failed with %ld\n",
PTR_ERR(dsi->te_gpio));
- goto out;
+ return PTR_ERR(dsi->te_gpio);
}
te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
@@ -1348,11 +1348,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi,
if (ret) {
dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
gpiod_put(dsi->te_gpio);
- goto out;
+ return ret;
}
-out:
- return ret;
+ return 0;
}
static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
--
2.25.1
Re: [PATCH 1/3] drm/exynox: Implement mmap as GEM object function
Hi Thomas and Daniel,
21. 11. 9. 오전 12:29에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Nov 08, 2021 at 11:28:44AM +0100, Thomas Zimmermann wrote:
>> Moving the driver-specific mmap code into a GEM object function allows
>> for using DRM helpers for various mmap callbacks.
>>
>> The respective exynos functions are being removed. The file_operations
>> structure exynos_drm_driver_fops is now being created by the helper macro
>> DEFINE_DRM_GEM_FOPS().
>>
>> Signed-off-by: Thomas Zimmermann
>
> s/exynox/exynos in the subject.
>
> Patch lgtm, but would still be good if exynos maintainers would
> ack/review/test it. But if you don't get anything within 2 weeks here's
Sorry for late. Confirmed working well on Odroid board, and had a review.
Applied.
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next
Thanks,
Inki Dae
> my:
>
> Acked-by: Daniel Vetter
>
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 ++-
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++-
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 43 +--
>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 5 ---
>> 4 files changed, 13 insertions(+), 68 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index d8f1cf4d6b69..9743b6b17447 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -102,16 +102,7 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
>> DRM_RENDER_ALLOW),
>> };
>>
>> -static const struct file_operations exynos_drm_driver_fops = {
>> -.owner = THIS_MODULE,
>> -.open = drm_open,
>> -.mmap = exynos_drm_gem_mmap,
>> -.poll = drm_poll,
>> -.read = drm_read,
>> -.unlocked_ioctl = drm_ioctl,
>> -.compat_ioctl = drm_compat_ioctl,
>> -.release= drm_release,
>> -};
>> +DEFINE_DRM_GEM_FOPS(exynos_drm_driver_fops);
>>
>> static const struct drm_driver exynos_drm_driver = {
>> .driver_features= DRIVER_MODESET | DRIVER_GEM
>> @@ -124,7 +115,7 @@ static const struct drm_driver exynos_drm_driver = {
>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> .gem_prime_import = exynos_drm_gem_prime_import,
>> .gem_prime_import_sg_table = exynos_drm_gem_prime_import_sg_table,
>> -.gem_prime_mmap = exynos_drm_gem_prime_mmap,
>> +.gem_prime_mmap = drm_gem_prime_mmap,
>> .ioctls = exynos_ioctls,
>> .num_ioctls = ARRAY_SIZE(exynos_ioctls),
>> .fops = _drm_driver_fops,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index 5147f5929be7..02c97b9ca926 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -39,25 +40,8 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
>> struct drm_fb_helper *helper = info->par;
>> struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(helper);
>> struct exynos_drm_gem *exynos_gem = exynos_fbd->exynos_gem;
>> -unsigned long vm_size;
>> -int ret;
>> -
>> -vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>> -
>> -vm_size = vma->vm_end - vma->vm_start;
>> -
>> -if (vm_size > exynos_gem->size)
>> -return -EINVAL;
>>
>> -ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
>> - exynos_gem->dma_addr, exynos_gem->size,
>> - exynos_gem->dma_attrs);
>> -if (ret < 0) {
>> -DRM_DEV_ERROR(to_dma_dev(helper->dev), "failed to mmap.\n");
>> -return ret;
>> -}
>> -
>> -return 0;
>> +return drm_gem_prime_mmap(_gem->base, vma);
>> }
>>
>> static const struct fb_ops exynos_drm_fb_ops = {
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 4396224227d1..c4b63902ee7a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -17,6 +17,8 @@
>> #include
Re: [PATCH] drm/exynos: Replace legacy gpio interface for gpiod interface
Hi,
21. 11. 2. 오전 11:20에 Maíra Canal 이(가) 쓴 글:
> Considering the current transition of the GPIO subsystem, remove all
> dependencies of the legacy GPIO interface (linux/gpio.h and linux
> /of_gpio.h) and replace it with the descriptor-based GPIO approach.
>
Applied.
Thanks,
Inki Dae
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +
> 1 file changed, 14 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8d137857818c..b0b1acb7e712 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -13,7 +13,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -265,7 +264,7 @@ struct exynos_dsi {
> struct clk **clks;
> struct regulator_bulk_data supplies[2];
> int irq;
> - int te_gpio;
> + struct gpio_desc *te_gpio;
>
> u32 pll_clk_rate;
> u32 burst_clk_rate;
> @@ -1298,14 +1297,14 @@ static void exynos_dsi_enable_irq(struct exynos_dsi
> *dsi)
> {
> enable_irq(dsi->irq);
>
> - if (gpio_is_valid(dsi->te_gpio))
> - enable_irq(gpio_to_irq(dsi->te_gpio));
> + if (dsi->te_gpio)
> + enable_irq(gpiod_to_irq(dsi->te_gpio));
> }
>
> static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
> {
> - if (gpio_is_valid(dsi->te_gpio))
> - disable_irq(gpio_to_irq(dsi->te_gpio));
> + if (dsi->te_gpio)
> + disable_irq(gpiod_to_irq(dsi->te_gpio));
>
> disable_irq(dsi->irq);
> }
> @@ -1335,29 +1334,20 @@ static int exynos_dsi_register_te_irq(struct
> exynos_dsi *dsi,
> int ret;
> int te_gpio_irq;
>
> - dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
> - if (dsi->te_gpio == -ENOENT)
> - return 0;
> -
> - if (!gpio_is_valid(dsi->te_gpio)) {
> - ret = dsi->te_gpio;
> - dev_err(dsi->dev, "cannot get te-gpios, %d\n", ret);
> + dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
> + if (IS_ERR(dsi->te_gpio)) {
> + dev_err(dsi->dev, "gpio request failed with %ld\n",
> + PTR_ERR(dsi->te_gpio));
> goto out;
> }
>
> - ret = gpio_request(dsi->te_gpio, "te_gpio");
> - if (ret) {
> - dev_err(dsi->dev, "gpio request failed with %d\n", ret);
> - goto out;
> - }
> -
> - te_gpio_irq = gpio_to_irq(dsi->te_gpio);
> + te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
>
> ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
> IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE",
> dsi);
> if (ret) {
> dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
> - gpio_free(dsi->te_gpio);
> + gpiod_put(dsi->te_gpio);
> goto out;
> }
>
> @@ -1367,10 +1357,9 @@ static int exynos_dsi_register_te_irq(struct
> exynos_dsi *dsi,
>
> static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
> {
> - if (gpio_is_valid(dsi->te_gpio)) {
> - free_irq(gpio_to_irq(dsi->te_gpio), dsi);
> - gpio_free(dsi->te_gpio);
> - dsi->te_gpio = -ENOENT;
> + if (dsi->te_gpio) {
> + free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
> + gpiod_put(dsi->te_gpio);
> }
> }
>
> @@ -1745,9 +1734,6 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> if (!dsi)
> return -ENOMEM;
>
> - /* To be checked as invalid one */
> - dsi->te_gpio = -ENOENT;
> -
> init_completion(>completed);
> spin_lock_init(>transfer_lock);
> INIT_LIST_HEAD(>transfer_list);
>
Re: [PATCH 1/3] drm/exynox: Implement mmap as GEM object function
Hi,
Really sorry for late. I saw this patch in my mailbox just before. Seems I
missed it due to a typo, exynox.
I will review and apply this patch ASAP.
Thanks,
Inki Dae
21. 11. 8. 오후 7:28에 Thomas Zimmermann 이(가) 쓴 글:
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> The respective exynos functions are being removed. The file_operations
> structure exynos_drm_driver_fops is now being created by the helper macro
> DEFINE_DRM_GEM_FOPS().
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 43 +--
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 5 ---
> 4 files changed, 13 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index d8f1cf4d6b69..9743b6b17447 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -102,16 +102,7 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_RENDER_ALLOW),
> };
>
> -static const struct file_operations exynos_drm_driver_fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .mmap = exynos_drm_gem_mmap,
> - .poll = drm_poll,
> - .read = drm_read,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .release= drm_release,
> -};
> +DEFINE_DRM_GEM_FOPS(exynos_drm_driver_fops);
>
> static const struct drm_driver exynos_drm_driver = {
> .driver_features= DRIVER_MODESET | DRIVER_GEM
> @@ -124,7 +115,7 @@ static const struct drm_driver exynos_drm_driver = {
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import = exynos_drm_gem_prime_import,
> .gem_prime_import_sg_table = exynos_drm_gem_prime_import_sg_table,
> - .gem_prime_mmap = exynos_drm_gem_prime_mmap,
> + .gem_prime_mmap = drm_gem_prime_mmap,
> .ioctls = exynos_ioctls,
> .num_ioctls = ARRAY_SIZE(exynos_ioctls),
> .fops = _drm_driver_fops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 5147f5929be7..02c97b9ca926 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -39,25 +40,8 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
> struct drm_fb_helper *helper = info->par;
> struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(helper);
> struct exynos_drm_gem *exynos_gem = exynos_fbd->exynos_gem;
> - unsigned long vm_size;
> - int ret;
> -
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> -
> - vm_size = vma->vm_end - vma->vm_start;
> -
> - if (vm_size > exynos_gem->size)
> - return -EINVAL;
>
> - ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
> - exynos_gem->dma_addr, exynos_gem->size,
> - exynos_gem->dma_attrs);
> - if (ret < 0) {
> - DRM_DEV_ERROR(to_dma_dev(helper->dev), "failed to mmap.\n");
> - return ret;
> - }
> -
> - return 0;
> + return drm_gem_prime_mmap(_gem->base, vma);
> }
>
> static const struct fb_ops exynos_drm_fb_ops = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4396224227d1..c4b63902ee7a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -17,6 +17,8 @@
> #include "exynos_drm_drv.h"
> #include "exynos_drm_gem.h"
>
> +static int exynos_drm_gem_mmap(struct drm_gem_object *obj, struct
> vm_area_struct *vma);
> +
> static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem, bool
> kvmap)
> {
> struct drm_device *dev = exynos_gem->base.dev;
> @@ -135,6 +137,7 @@ static const struct vm_operations_struct
> exynos_drm_gem_vm_ops = {
> static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
> .free = exynos_drm_gem_free_object,
> .get_sg_table = exynos_drm_gem_prime_get_sg_table,
> + .mmap = exynos_drm_gem_mmap,
> .vm_ops =
Re: [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
21. 10. 27. 오전 7:28에 Inki Dae 이(가) 쓴 글: > Hi, > > 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글: >> Once EDID is parsed, the monitor HDMI support information is available >> through drm_display_info.is_hdmi. Retriving the same information with >> drm_detect_hdmi_monitor() is less efficient. Change to >> drm_display_info.is_hdmi >> >> Signed-off-by: Claudio Suarez >> --- >> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions( >> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c >> b/drivers/gpu/drm/exynos/exynos_hdmi.c >> index 7655142a4651..a563d6386abe 100644 >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c >> @@ -893,12 +893,14 @@ static int hdmi_get_modes(struct drm_connector >> *connector) >> if (!edid) >> return -ENODEV; >> >> -hdata->dvi_mode = !drm_detect_hdmi_monitor(edid); >> +/* This updates connector->display_info */ >> +drm_connector_update_edid_property(connector, edid); >> + >> +hdata->dvi_mode = !connector->display_info.is_hdmi; > > Thanks for correcting this. Yeah, we should use drm_display_info.is_hdmi > parsed from EDID. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725 > > Signed-off-by: Inki Dae My mistake. Please, ignore above Signed-off-by. Acked-by : Inki Dae instead. Thanks, Inki Dae > > Thanks, > Inki Dae > >> DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n", >>(hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"), >>edid->width_cm, edid->height_cm); >> >> -drm_connector_update_edid_property(connector, edid); >> cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid); >> >> ret = drm_add_edid_modes(connector, edid); >> >
Re: [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
Hi, 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글: > Once EDID is parsed, the monitor HDMI support information is available > through drm_display_info.is_hdmi. Retriving the same information with > drm_detect_hdmi_monitor() is less efficient. Change to > drm_display_info.is_hdmi > > Signed-off-by: Claudio Suarez > --- > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions( > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 7655142a4651..a563d6386abe 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -893,12 +893,14 @@ static int hdmi_get_modes(struct drm_connector > *connector) > if (!edid) > return -ENODEV; > > - hdata->dvi_mode = !drm_detect_hdmi_monitor(edid); > + /* This updates connector->display_info */ > + drm_connector_update_edid_property(connector, edid); > + > + hdata->dvi_mode = !connector->display_info.is_hdmi; Thanks for correcting this. Yeah, we should use drm_display_info.is_hdmi parsed from EDID. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725 Signed-off-by: Inki Dae Thanks, Inki Dae > DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n", > (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"), > edid->width_cm, edid->height_cm); > > - drm_connector_update_edid_property(connector, edid); > cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid); > > ret = drm_add_edid_modes(connector, edid); >
[GIT PULL] exynos-drm-fixes
Hi Dave, Just one clean up to use helper function. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f: Linux 5.15-rc1 (2021-09-12 16:28:37 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v5.15-rc4 for you to fetch changes up to 17ac76e050c51497e75871a43aa3328ba54cdafd: drm/exynos: Make use of the helper function devm_platform_ioremap_resource() (2021-09-16 14:05:07 +0900) One cleanup - Use devm_platform_ioremap_resource() helper function instead of old one. Cai Huoqing (1): drm/exynos: Make use of the helper function devm_platform_ioremap_resource() drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 + drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 4 +--- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +--- 9 files changed, 9 insertions(+), 31 deletions(-)
Re: [PATCH] drm/exynos: Make use of the helper function devm_platform_ioremap_resource()
21. 8. 31. 오후 4:49에 Cai Huoqing 이(가) 쓴 글:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
Picked it up.
Thanks,
Inki Dae
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +---
> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 4 +---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +---
> 9 files changed, 9 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 9870c4e6af36..b5001db7a95c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -793,7 +793,6 @@ static int exynos5433_decon_probe(struct platform_device
> *pdev)
> {
> struct device *dev = >dev;
> struct decon_context *ctx;
> - struct resource *res;
> int ret;
> int i;
>
> @@ -818,8 +817,7 @@ static int exynos5433_decon_probe(struct platform_device
> *pdev)
> ctx->clks[i] = clk;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - ctx->addr = devm_ioremap_resource(dev, res);
> + ctx->addr = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(ctx->addr))
> return PTR_ERR(ctx->addr);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e39fac889edc..8d137857818c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1738,7 +1738,6 @@ static const struct component_ops
> exynos_dsi_component_ops = {
> static int exynos_dsi_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> - struct resource *res;
> struct exynos_dsi *dsi;
> int ret, i;
>
> @@ -1789,8 +1788,7 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> }
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - dsi->reg_base = devm_ioremap_resource(dev, res);
> + dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(dsi->reg_base))
> return PTR_ERR(dsi->reg_base);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index a3c718148c45..ecfd82d0afb7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -85,7 +85,6 @@ struct fimc_scaler {
> /*
> * A structure of fimc context.
> *
> - * @regs_res: register resources.
> * @regs: memory mapped io registers.
> * @lock: locking of operations.
> * @clocks: fimc clocks.
> @@ -103,7 +102,6 @@ struct fimc_context {
> struct exynos_drm_ipp_formats *formats;
> unsigned intnum_formats;
>
> - struct resource *regs_res;
> void __iomem*regs;
> spinlock_t lock;
> struct clk *clocks[FIMC_CLKS_MAX];
> @@ -1327,8 +1325,7 @@ static int fimc_probe(struct platform_device *pdev)
> ctx->num_formats = num_formats;
>
> /* resource memory */
> - ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - ctx->regs = devm_ioremap_resource(dev, ctx->regs_res);
> + ctx->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(ctx->regs))
> return PTR_ERR(ctx->regs);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 700ca4fa6665..c735e53939d8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1202,9 +1202,7 @@ static int fimd_probe(struct platform_device *pdev)
> return PTR_ERR(ctx->lcd_clk);
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> - ctx->regs = devm_ioremap_resource(dev, res);
> + ctx->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(ctx->regs))
> return PTR_ERR(ctx->regs);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index b00230626c6a..47
[GIT PULL] exynos-drm-next
Hi Dave, Just two fixups - fixing one build warning and missing unlock, and one cleanup - replaceing atomic_t with refcount_t. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 397ab98e2d69cede8a28eab77a171983d14e: Merge tag 'drm-msm-next-2021-08-12' of https://gitlab.freedesktop.org/drm/msm into drm-next (2021-08-17 10:53:52 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.15 for you to fetch changes up to c626f386428bbe06476b0b497c1330aa4463: drm/exynos: Always initialize mapping in exynos_drm_register_dma() (2021-08-22 01:56:39 +0900) Two fixups - Fix missing unlock issue in exynos_drm_g2d.c - Fix a build warning in exynos_drm_dma.c One cleanup - Replace atomic_t with refcount_t in exynos_drm_g2d.c Nathan Chancellor (1): drm/exynos: Always initialize mapping in exynos_drm_register_dma() Wei Yongjun (1): drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker() Xiyu Yang (1): drm/exynos: Convert from atomic_t to refcount_t on g2d_cmdlist_userptr->refcount drivers/gpu/drm/exynos/exynos_drm_dma.c | 2 ++ drivers/gpu/drm/exynos/exynos_drm_g2d.c | 14 -- 2 files changed, 10 insertions(+), 6 deletions(-)
Re: [RFC PATCH 06/17] drm/exynos: dsi: Handle exynos specifics via driver_data
Hi Laurent, 21. 8. 13. 오후 9:16에 Laurent Pinchart 이(가) 쓴 글: > Hi Inki, > > On Fri, Aug 13, 2021 at 03:50:56PM +0900, Inki Dae wrote: >> 21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글: >>> On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote: >>>> Exynos DSI driver is actually a Samsung MIPI DSIM bridge >>>> IP which is also used in i.MX8MM platforms. >>>> >>>> Right now the existing driver has some exynos drm specific >>>> code bases like te_irq, crtc and component_ops. >>>> >>>> In order to switch this driver into a common bridge driver >>>> We can see 2 options to handle the exynos specific code. >>>> >>>> A. Drop the component_ops, and rework other specifics. >>>>This may lead to more foundation work as it requires >>>>more changes in exynos drm drivers stack. >>>> >>>> B. Handle the exynos specifics via driver data, and make >>>>the common bridge work in different platforms and plan >>>>for option A in future. >>>> >>>> So, this patch is trying to add option B) changes to handle >>>> exynos specifics via driver_data. >>> >>> We really should find someone that has the time, energy, knowledge and >>> hardware that can include device_link support once anf for all for >>> bridges. >>> Then we would avoid hacks like this. >>> >>> I see no other options at the moment, but look forward for a better >>> solution. >> >> I'm not sure that it's correct to share this mipi dsi driver with >> I.MX8MM SoC even though it's a same IP because this MIPI DSI device >> isn't peripheral device but in SoC. >> >> It would mean that Exynos MIPI DSI device depends on SoC architecture, >> and Exynos and I.MX series are totally different SoC. So if we share >> the same driver for the MIPI DSI device then many things we didn't >> predict may happen in the future. > > Isn't that true for external components true thought ? Any driver shared > by multiple systems will face this issue, where it will be developed > with some use cases in mind, and regressions may happen when the driver > is then extended to support other use cases not required for the > original platform. > > In general we don't want multiple drivers for the same IP core unless > there are valid technical reasons for that. It's the whole point of the > device tree, being able to describe how IP cores are integrated, so that > code can be reused across platforms. Of course, integration differences > between SoCs can sometimes vary wildly and require some amount of glue > code. Agree with you. It would be a good chance to clarify what we need to share same device driver without any regress in this time. > >> I don't want to make Jagan's efforts >> in vain for the community but clarify whether this is correct way or >> not. If this is only the way we have to go then we could more focus on >> actual solution not such hack. Impossible work with Jagan alone I >> think. > > I do agree that we need more correct solutions and less hacks in general > :-) The issues faced on Exynos also exist on other platforms, so it > would be much better to solve them well once that duplicating > implementations with less test coverage and reviews. There have been > efforts in the past to address some of these issues, which have resulted > in solutions such as the component framework. However, I'd argued that Yeah, most of ARM systems have various separate devices but DRM subsytem wanted each ARM driver to work like one device driver for all of them. And the component framework has been adopted by several ARM DRM drivers for it including Exynos. > we've never taken it to the last step, and have always stopped with half > solutions. The component framework, for instance, is painful to use, and > the handling of .remove() in most drivers is completely broken because > of that (not just because of that though, we have issues in the DRM core > that make hot-unplug just impossible to handle safetly). This may be one of what we have to clarify. I think ARM DRM drivers need component framework or similar thing to address probing order issue. So would we need to enhance existing compoent framework to be suitable for DRM subsystem, or introducing an alternative solution? Otherwise, would there be some way to address the probing order issue without the compoment framework? > >> So let's get started with a question, >> - Is MIPI-DSI bridge device or Encoder device? I think that MIPI-DSI >> is a Encoder device managed by atomic KMS. If MIPI-DSI should be >> hand
Re: [RFC PATCH 06/17] drm/exynos: dsi: Handle exynos specifics via driver_data
Hi,
21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글:
> On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote:
>> Exynos DSI driver is actually a Samsung MIPI DSIM bridge
>> IP which is also used in i.MX8MM platforms.
>>
>> Right now the existing driver has some exynos drm specific
>> code bases like te_irq, crtc and component_ops.
>>
>> In order to switch this driver into a common bridge driver
>> We can see 2 options to handle the exynos specific code.
>>
>> A. Drop the component_ops, and rework other specifics.
>>This may lead to more foundation work as it requires
>>more changes in exynos drm drivers stack.
>>
>> B. Handle the exynos specifics via driver data, and make
>>the common bridge work in different platforms and plan
>>for option A in future.
>>
>> So, this patch is trying to add option B) changes to handle
>> exynos specifics via driver_data.
>
> We really should find someone that has the time, energy, knowledge and
> hardware that can include device_link support once anf for all for
> bridges.
> Then we would avoid hacks like this.
>
> I see no other options at the moment, but look forward for a better
> solution.
>
> Sam
>
I'm not sure that it's correct to share this mipi dsi driver with I.MX8MM SoC
even though it's a same IP because this MIPI DSI device isn't peripheral device
but in SoC.
It would mean that Exynos MIPI DSI device depends on SoC architecture, and
Exynos and I.MX series are totally different SoC. So if we share the same
driver for the MIPI DSI device then many things we didn't predict may happen in
the future. I don't want to make Jagan's efforts in vain for the community but
clarify whether this is correct way or not. If this is only the way we have to
go then we could more focus on actual solution not such hack. Impossible work
with Jagan alone I think.
So let's get started with a question,
- Is MIPI-DSI bridge device or Encoder device? I think that MIPI-DSI is a
Encoder device managed by atomic KMS. If MIPI-DSI should be handled as bridge
device then does now drm bridge framework provide everything to share one
driver with one more SoC? I mean something that drm bridge has to consider for
such driver support, which is shared with one more SoC.
And Display mode - VIDEO and COMMAND mode - is generic type of MIPI DSI, and
also componentised subsystem is a generic solution to resolve probing order
issue not Exynos specific feature. These are driver specific ones not Exynos
SoC I think. As SoC specific things should be considered, I think MIPI DSI
Driver - interrupt handler and probing order things are really specific to
device driver - should be separated but we could share the control part of the
device.
I was busy with other projects so didn't care of Linux DRM world so there may
be my missing something.
Thanks,
Inki Dae
>
>>
>> Signed-off-by: Jagan Teki
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 37 +++--
>> 1 file changed, 29 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 99a1b8c22313..53d878d4d2d7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -250,6 +250,7 @@ struct exynos_dsi_driver_data {
>> unsigned int wait_for_reset;
>> unsigned int num_bits_resol;
>> const unsigned int *reg_values;
>> +bool exynos_specific;
>> };
>>
>> struct exynos_dsi {
>> @@ -459,6 +460,7 @@ static const struct exynos_dsi_driver_data
>> exynos3_dsi_driver_data = {
>> .wait_for_reset = 1,
>> .num_bits_resol = 11,
>> .reg_values = reg_values,
>> +.exynos_specific = true,
>> };
>>
>> static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
>> @@ -471,6 +473,7 @@ static const struct exynos_dsi_driver_data
>> exynos4_dsi_driver_data = {
>> .wait_for_reset = 1,
>> .num_bits_resol = 11,
>> .reg_values = reg_values,
>> +.exynos_specific = true,
>> };
>>
>> static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>> @@ -481,6 +484,7 @@ static const struct exynos_dsi_driver_data
>> exynos5_dsi_driver_data = {
>> .wait_for_reset = 1,
>> .num_bits_resol = 11,
>> .reg_values = reg_values,
>> +.exynos_specific = true,
>> };
>>
>> static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
>> @@ -492,6 +496,7 @@ static const struct exynos_dsi_driver_data
>> exynos5433_dsi_drive
Re: [PATCH -next] drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker()
Sorry for late and thanks for fixing it.
Thanks,
Inki Dae
2021년 6월 16일 수요일, Wei Yongjun 님이 작성:
> Add the missing unlock before return from function g2d_runqueue_worker()
> in the error handling case.
>
> Fixes: 445d3bed75de ("drm/exynos: use pm_runtime_resume_and_get()")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index cab4d2c370a7..0ed665501ac4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -897,13 +897,14 @@ static void g2d_runqueue_worker(struct work_struct
> *work)
> ret = pm_runtime_resume_and_get(g2d->dev);
> if (ret < 0) {
> dev_err(g2d->dev, "failed to enable G2D
> device.\n");
> - return;
> + goto out;
> }
>
> g2d_dma_start(g2d, g2d->runqueue_node);
> }
> }
>
> +out:
> mutex_unlock(>runqueue_mutex);
> }
>
>
>
[GIT PULL] exynos-drm-next
Hi Dave, Just two cleanups to replace pm_runtime_get_sync() with pm_runtime_resume_and_get(). Please kinkdly let me know if there is any problem. Thanks, Inki Dae The following changes since commit c707b73f0cfb1acc94a20389aecde65e6385349b: Merge tag 'amd-drm-next-5.14-2021-06-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-06-10 13:47:13 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.14 for you to fetch changes up to 445d3bed75de4082c7c7794030ac9a5b8bfde886: drm/exynos: use pm_runtime_resume_and_get() (2021-06-11 10:56:38 +0900) Two cleanups - These patches make Exynos DRM driver to use pm_runtime_resume_and_get() function instead of m_runtime_get_sync() to deal with usage counter. pm_runtime_get_sync() increases the usage counter even when it failed, which could make callers to forget to decrease the usage counter. pm_runtime_resume_and_get() decreases the usage counter regardless of whether it failed or not. Inki Dae (1): drm/exynos: use pm_runtime_resume_and_get() Tian Tao (1): drm/exynos: Use pm_runtime_resume_and_get() to replace open coding drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 ++- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 ++- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 ++- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 8 +++- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 9 - drivers/gpu/drm/exynos/exynos_drm_gsc.c | 7 ++- drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_rotator.c | 7 ++- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 10 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 8 +++- drivers/gpu/drm/exynos/exynos_mixer.c | 7 ++- 12 files changed, 86 insertions(+), 22 deletions(-)
[PATCH v2] drm/exynos: use pm_runtime_resume_and_get()
Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()
to deal with usage counter. pm_runtime_get_sync() increases the
usage counter even when it failed, which makes callers to forget
to decrease the usage counter and resulted in reference leak.
pm_runtime_resume_and_get() function decreases the usage counter
when it failed internally so it can avoid the reference leak.
Changelog v1:
- Fix an build error reported by kernel test robot of Intel.
Signed-off-by: Inki Dae
Reported-by: kernel test robot
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 8 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 +++
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 9 ++-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c| 10 +---
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-
11 files changed, 84 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b9a4b7670a89..63dd85af13f2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -513,8 +513,13 @@ static void decon_swreset(struct decon_context *ctx)
static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
+ int ret;
- pm_runtime_get_sync(ctx->dev);
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "failed to enable DECON device.\n");
+ return;
+ }
exynos_drm_pipe_clk_enable(crtc, true);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 431c5d32f9a4..b61edc54e66f 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -531,11 +531,16 @@ static void decon_init(struct decon_context *ctx)
static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
+ int ret;
if (!ctx->suspended)
return;
- pm_runtime_get_sync(ctx->dev);
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "failed to enable DECON device.\n");
+ return;
+ }
decon_init(ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 44e402b7cdfb..5bb1388a8b18 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1383,7 +1383,12 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
+ ret = pm_runtime_resume_and_get(dsi->dev);
+ if (ret < 0) {
+ dev_err(dsi->dev, "failed to enable DSI device.\n");
+ return;
+ }
+
dsi->state |= DSIM_STATE_ENABLED;
if (dsi->panel) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 29ab8be8604c..a3c718148c45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1085,8 +1085,14 @@ static int fimc_commit(struct exynos_drm_ipp *ipp,
{
struct fimc_context *ctx =
container_of(ipp, struct fimc_context, ipp);
+ int ret;
+
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ dev_err(ctx->dev, "failed to enable FIMC device.\n");
+ return ret;
+ }
- pm_runtime_get_sync(ctx->dev);
ctx->task = task;
fimc_src_set_fmt(ctx, task->src.buf.fourcc, task->src.buf.modifier);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 49a2e0c53918..5955bd90accb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -343,13 +343,18 @@ static void fimd_enable_shadow_channel_path(struct
fimd_context *ctx,
writel(val, ctx->regs + SHADOWCON);
}
-static void fimd_clear_channels(struct exynos_drm_crtc *crtc)
+static int fimd_clear_channels(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
+ int ret;
/* Hardware is in unknown state, so ensure it gets enabled properly */
- pm_runtime_g
[PATCH] drm/exynos: use pm_runtime_resume_and_get()
Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()
to deal with usage counter. pm_runtime_get_sync() increases the
usage counter even when it failed, which makes callers to forget
to decrease the usage counter and resulted in reference leak.
pm_runtime_resume_and_get() function decreases the usage counter
when it failed internally so it can avoid the reference leak.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 8 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 +++
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 9 ++-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 7 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c| 10 +---
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-
11 files changed, 84 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b9a4b7670a89..63dd85af13f2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -513,8 +513,13 @@ static void decon_swreset(struct decon_context *ctx)
static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
+ int ret;
- pm_runtime_get_sync(ctx->dev);
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "failed to enable DECON device.\n");
+ return;
+ }
exynos_drm_pipe_clk_enable(crtc, true);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 431c5d32f9a4..b61edc54e66f 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -531,11 +531,16 @@ static void decon_init(struct decon_context *ctx)
static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
+ int ret;
if (!ctx->suspended)
return;
- pm_runtime_get_sync(ctx->dev);
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "failed to enable DECON device.\n");
+ return;
+ }
decon_init(ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 44e402b7cdfb..5bb1388a8b18 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1383,7 +1383,12 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
+ ret = pm_runtime_resume_and_get(dsi->dev);
+ if (ret < 0) {
+ dev_err(dsi->dev, "failed to enable DSI device.\n");
+ return;
+ }
+
dsi->state |= DSIM_STATE_ENABLED;
if (dsi->panel) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 29ab8be8604c..a3c718148c45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1085,8 +1085,14 @@ static int fimc_commit(struct exynos_drm_ipp *ipp,
{
struct fimc_context *ctx =
container_of(ipp, struct fimc_context, ipp);
+ int ret;
+
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+ dev_err(ctx->dev, "failed to enable FIMC device.\n");
+ return ret;
+ }
- pm_runtime_get_sync(ctx->dev);
ctx->task = task;
fimc_src_set_fmt(ctx, task->src.buf.fourcc, task->src.buf.modifier);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 49a2e0c53918..5955bd90accb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -343,13 +343,18 @@ static void fimd_enable_shadow_channel_path(struct
fimd_context *ctx,
writel(val, ctx->regs + SHADOWCON);
}
-static void fimd_clear_channels(struct exynos_drm_crtc *crtc)
+static int fimd_clear_channels(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
+ int ret;
/* Hardware is in unknown state, so ensure it gets enabled properly */
- pm_runtime_get_sync(ctx->dev);
+ ret = pm_runtime_resume_and_get(ctx->dev);
+ if (ret < 0) {
+
Re: [PATCH v2] drm/exynos: Use pm_runtime_resume_and_get() to replace open coding
21. 5. 22. 오전 12:31에 Daniel Vetter 이(가) 쓴 글:
> On Fri, May 21, 2021 at 05:06:06PM +0800, Tian Tao wrote:
>> use pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
>> pm_runtime_put_noidle.
>
> It would be good to explain why: Apparently get_sync increments the
> refcount even if it fails, which ususally leads to leaks.
Tian Tao, could you update the description?
Thanks,
Inki Dae
>
> With that or similar added to the commit message:
>
> Reviewed-by: Daniel Vetter
>
>>
>> Signed-off-by: Tian Tao
>> ---
>>
>> v2: drop unnecessary change about if condition.
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> index 3821ea7..32672bf 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>> @@ -268,11 +268,9 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>> if (mic->enabled)
>> goto unlock;
>>
>> -ret = pm_runtime_get_sync(mic->dev);
>> -if (ret < 0) {
>> -pm_runtime_put_noidle(mic->dev);
>> +ret = pm_runtime_resume_and_get(mic->dev);
>> +if (ret < 0)
>> goto unlock;
>> -}
>>
>> mic_set_path(mic, 1);
>>
>> --
>> 2.7.4
>>
>
[GIT PULL] exynos-drm-fixes
Hi Dave, Just one fixup to kerneldoc and two cleanups to drop redundant error messages. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc: Linux 5.13-rc2 (2021-05-16 15:27:44 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v5.13-rc3 for you to fetch changes up to a470c5665b3b918c31bcc912234862803b10ba00: drm/exynos/decon5433: Remove redundant error printing in exynos5433_decon_probe() (2021-05-17 20:31:39 +0900) Fixup - Correct kerneldoc of fimd_shadow_protect_win function. Cleanup - Drop redundant error messages. Krzysztof Kozlowski (1): drm/exynos: correct exynos_drm_fimd kerneldoc Zhen Lei (2): drm/exynos: Remove redundant error printing in exynos_dsi_probe() drm/exynos/decon5433: Remove redundant error printing in exynos5433_decon_probe() drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +--- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 3 files changed, 3 insertions(+), 7 deletions(-)
Re: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly
21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatically as part of plane init, if drivers set the > modifier list correctly. Which is the case here. > > Signed-off-by: Daniel Vetter Acked-by: Inki Dae Thanks, Inki Dae > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Krzysztof Kozlowski > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > --- > drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c > b/drivers/gpu/drm/exynos/exynos_drm_fb.c > index 64370b634cca..79fa3649185c 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c > @@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev) > dev->mode_config.funcs = _drm_mode_config_funcs; > dev->mode_config.helper_private = _drm_mode_config_helpers; > > - dev->mode_config.allow_fb_modifiers = true; > - > dev->mode_config.normalize_zpos = true; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-next
Hi Dave, Just one patch to clean up the use of request_irq funtion. This patch has a dependency of one patch[1] so merged it on top of tag 'irq-no-autoen-2021-03-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip after top of drm next branch. Please kindly let me know if there is any problem. Thanks, Inki Dae [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552 The following changes since commit 99e5730dd2b11fedc890bbc9c803f69aad24e3ca: Merge tag 'irq-no-autoen-2021-03-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into exynos-drm-next (2021-03-29 20:35:13 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.13 for you to fetch changes up to a4e5eed2c6a689ef2b6ad8d7ae86665c69039379: drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag (2021-03-29 20:37:17 +0900) One cleanup - Based on the patch[1], clean up the use of request_irq function series. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552 Tian Tao (1): drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++ 2 files changed, 5 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-fixes
Hi Dave, Just one cleanup to drop unused header inclusion. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 09d78dde88ef95a27b54a6e450ee700ccabdf39d: Merge tag 'drm-msm-fixes-2021-02-25' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2021-03-26 13:04:17 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v5.12-rc6 for you to fetch changes up to 6161a435c1910d07ee00cc25af010889010e1f08: drm/exynos/decon5433: Remove the unused include statements (2021-03-29 19:53:23 +0900) Just one cleanup which drops of_gpio.h inclusion. - This header file isn't used anymore so drop it. Tian Tao (1): drm/exynos/decon5433: Remove the unused include statements drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 - 1 file changed, 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/decon5433: Clean up GPIO includes
21. 3. 15. 오후 3:45에 tiantao (H) 이(가) 쓴 글: > > 在 2021/3/15 14:35, Inki Dae 写道: >> Hi Tian Tao, >> >> 21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글: >>> remove the legacy GPIO headers but what it really >>> uses is since only gpio_desc structs are ever >>> referenced. >> This driver doesn't reference even linux/gpio/consumer.h so could you drop >> only of_gpio.h inclusion? > > Thanks for helping to review patch,I've posted a new patch to fix this > problem If you can give me review-by, I can help push to drm-misc. I can merge this patch and other one[1] to exynos drm tree after review, and will have a pull-request soon so no need to land to drm-misc tree. Let's not bother Daniel. :) [1] https://patchwork.kernel.org/project/dri-devel/patch/1615549385-33784-1-git-send-email-tiant...@hisilicon.com/ Thanks, Inki Dae > > Subject: [PATCH] drm/exynos/decon5433: Remove the unused include statements > > This driver doesn't reference of_gpio.h, so drop it. > > Signed-off-by: Tian Tao > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > index 1f79bc2..1510e4e 100644 > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > @@ -13,7 +13,6 @@ > #include > #include > #include > -#include > #include > #include > #include > >> >> Thanks, >> Inki Dae >> >>> Signed-off-by: Tian Tao >>> --- >>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c >>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c >>> index 1f79bc2..9fc51a6 100644 >>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c >>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c >>> @@ -11,9 +11,9 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> -#include >>> #include >>> #include >>> #include >>> >> . >> > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/decon5433: Clean up GPIO includes
Hi Tian Tao, 21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글: > remove the legacy GPIO headers but what it really > uses is since only gpio_desc structs are ever > referenced. This driver doesn't reference even linux/gpio/consumer.h so could you drop only of_gpio.h inclusion? Thanks, Inki Dae > > Signed-off-by: Tian Tao > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > index 1f79bc2..9fc51a6 100644 > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > @@ -11,9 +11,9 @@ > #include > #include > #include > +#include > #include > #include > -#include > #include > #include > #include > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-next
Hi Dave, Just a new mode support for HDMI and two clenups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 22f8c80566c4a29a0d8b5ebf24aa1fd1679b39e5: Merge tag 'drm-misc-next-2020-11-18' of ssh://git.freedesktop.org/git/drm/drm-misc into drm-next (2020-11-27 09:36:33 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.11 for you to fetch changes up to e11e6df2a86779cfc73c4fb2e957ff7a70d89f68: drm/exynos: use exynos_dsi as drvdata (2020-12-01 11:38:29 +0900) Add a new mode support for HDMI - support for 1920x1200x60Hz mode. Cleanups - Drop in_bridge_node from exynos_dsi - Use a exynos_dsi object instead of a encoder object as drvdata. Marek Szyprowski (1): drm/exynos/hdmi: add support for 1920x1200@60Hz mode Michael Tretter (2): drm/exynos: remove in_bridge_node from exynos_dsi drm/exynos: use exynos_dsi as drvdata drivers/gpu/drm/exynos/exynos_drm_dsi.c | 31 --- drivers/gpu/drm/exynos/exynos_hdmi.c| 9 + 2 files changed, 21 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-fixes
Hi Dave, Just one bug fix to a build error due to common framework dependency. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 6600f9d52213b5c3455481b5c9e61cf5e305c0e6: Merge tag 'drm-intel-fixes-2020-11-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-11-20 11:21:54 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v5.10-rc6 for you to fetch changes up to e2d3d2e904ad3d381753798dcd5cae03e3c47242: drm/exynos: depend on COMMON_CLK to fix compile tests (2020-11-23 10:01:32 +0900) One bug fix . Add COMMON_CLK dependency to fix a build error below, /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent' Krzysztof Kozlowski (1): drm/exynos: depend on COMMON_CLK to fix compile tests drivers/gpu/drm/exynos/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/exynos: depend on COMMON_CLK to fix compile tests
HI Krzysztof, 20. 11. 17. 오전 2:53에 Krzysztof Kozlowski 이(가) 쓴 글: > The Exynos DRM uses Common Clock Framework thus it cannot be built on > platforms without it (e.g. compile test on MIPS with RALINK and > SOC_RT305X): > > /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in > function `mixer_bind': > exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent' > > Reported-by: kernel test robot > Signed-off-by: Krzysztof Kozlowski Picked it up. Thanks, Inki Dae > --- > drivers/gpu/drm/exynos/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index 6417f374b923..951d5f708e92 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -1,7 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0-only > config DRM_EXYNOS > tristate "DRM Support for Samsung SoC Exynos Series" > - depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || > ARCH_MULTIPLATFORM || COMPILE_TEST) > + depends on OF && DRM && COMMON_CLK > + depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || > ARCH_MULTIPLATFORM || COMPILE_TEST > depends on MMU > select DRM_KMS_HELPER > select VIDEOMODE_HELPERS > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge
20. 11. 11. 오후 7:18에 Michael Tretter 이(가) 쓴 글: > On Wed, 11 Nov 2020 12:11:15 +0900, Inki Dae wrote: >> 20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글: >>> 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글: >>>> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote: >>>>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글: >>>>>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm >>>>>> bridge and make it usable with other drivers. Although the driver is >>>>>> converted, it still supports the component framework API to stay >>>>>> compliant >>>>>> with the Exynos DRM driver. >>>>>> >>>>>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the >>>>>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead >>>>>> of >>>>>> the Exynos Decon. The driver for the LCDIF does not use the component >>>>>> framework, but uses drm bridges. >>>>>> >>>>>> I don't have any Exynos SoC to actually test the series. I build a dummy >>>>>> to >>>>>> test the bridge with a component driver, to make sure that at least the >>>>>> initialization is working. Furthermore, tested the driver as a bridge >>>>>> with a >>>>>> few additional unfinished patches on the i.MX8M Mini EVK. However, >>>>>> somebody >>>>>> should verify that the driver is still working on Exynos hardware. >>>>>> >>>>>> I also changed the order of the patches to first make the driver more >>>>>> platform >>>>>> independent (patches 2 to 8), then convert to a drm bridge driver >>>>>> (patches 10 >>>>> >>>>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus >>>>> device >>>>> would be one of an encoder type of devices not bridge such as DSI to LVDS >>>>> and LVDS to DSI bridge devices, and also image enhancer and image >>>>> compressor >>>>> in case of Exynos. >>>> >>>> I don't understand, why the MIPI-DSI bus device would be an encoder type >>>> and >>>> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device >>>> tree >>>> documentation for the DSIM states that the DSIM receives RGB video as input >>>> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel >>>> RGB to >>> >>> MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then >>> transfers the packet to MIPI panel. >>> And finally, MIPI panel decodes the packet and updates it - RGB data - on >>> its SRAM. >>> >>> MIPI-DSI driver programs how the RGB video should be made as MIPI packet. >>> For more detail, you could refer to MIPI-DSI spec. >>> This would be why we handle MIPI-DSI driver as an encoder like other ARM >>> SoC DRM drivers did. >>> >>>> MIPI-DSI bridge and the encoder is the LCD controller that encodes the >>>> video >>>> data as parallel RGB. >>>> >>>> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series >>>> implements the encoder in the platform glue, but in the end the encoder can >>>> probably be moved to the DECON. >>> >>> As you know, Display controller can transfer RGB video to various devices >>> such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via >>> MIPI-DSI bus device, and so on like below, >>> >>> Display Controller --> RGB panel or CPU panel. >>> Display Controller --> LVDS bridge --> LVDS panel. >>> Display Controller --> MIPI DSI bus device --> MIPI Panel. >>> ... >>> >>> Display controller drivers such as FIMD and DECON series in case of Exynos >>> don't create an encoder driver-internally instead of it depends on Display >>> pipeline configuration - what kind of Display panel is used. >>> In fact, if the Display pipeline uses RGB panel or CPU panel without >>> Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an >>> encoder for it internally - just we separated the code to consider other >>> type of panels. > > What happens if I add a MIPI-DSI --> HDMI bridge to the Display pipeline? Then > the Pipeline is > > Display Contr
Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge
20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글: > > > 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글: >> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote: >>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글: >>>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm >>>> bridge and make it usable with other drivers. Although the driver is >>>> converted, it still supports the component framework API to stay compliant >>>> with the Exynos DRM driver. >>>> >>>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the >>>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of >>>> the Exynos Decon. The driver for the LCDIF does not use the component >>>> framework, but uses drm bridges. >>>> >>>> I don't have any Exynos SoC to actually test the series. I build a dummy to >>>> test the bridge with a component driver, to make sure that at least the >>>> initialization is working. Furthermore, tested the driver as a bridge with >>>> a >>>> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody >>>> should verify that the driver is still working on Exynos hardware. >>>> >>>> I also changed the order of the patches to first make the driver more >>>> platform >>>> independent (patches 2 to 8), then convert to a drm bridge driver (patches >>>> 10 >>> >>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus device >>> would be one of an encoder type of devices not bridge such as DSI to LVDS >>> and LVDS to DSI bridge devices, and also image enhancer and image compressor >>> in case of Exynos. >> >> I don't understand, why the MIPI-DSI bus device would be an encoder type and >> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device >> tree >> documentation for the DSIM states that the DSIM receives RGB video as input >> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel RGB >> to > > MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then > transfers the packet to MIPI panel. > And finally, MIPI panel decodes the packet and updates it - RGB data - on its > SRAM. > > MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For > more detail, you could refer to MIPI-DSI spec. > This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC > DRM drivers did. > >> MIPI-DSI bridge and the encoder is the LCD controller that encodes the video >> data as parallel RGB. >> >> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series >> implements the encoder in the platform glue, but in the end the encoder can >> probably be moved to the DECON. > > As you know, Display controller can transfer RGB video to various devices > such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via > MIPI-DSI bus device, and so on like below, > > Display Controller --> RGB panel or CPU panel. > Display Controller --> LVDS bridge --> LVDS panel. > Display Controller --> MIPI DSI bus device --> MIPI Panel. > ... > > Display controller drivers such as FIMD and DECON series in case of Exynos > don't create an encoder driver-internally instead of it depends on Display > pipeline configuration - what kind of Display panel is used. > In fact, if the Display pipeline uses RGB panel or CPU panel without Display > bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder > for it internally - just we separated the code to consider other type of > panels. > > On the I.MX8MM, could you share how to handle an encoder if some board has > only MIPI-DSI panel, and in this case, where is an encoder for it created? I > looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver. > Seems that they support only parallel display, HDMI and LVDS panel. One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - creates an encoder internally like MIPI-DSI driver of Exynos DRM did. > > Thanks, > Inki Dae > >> >>> Why do you want to convert such MIPI-DSI driver to bridge type of driver? >>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver >>> for Exynos with i.MX8M Mini? >> >> Yes, the reason is that the driver should be shared between Exynos and >> i.MX8MM. It is the same IP and I don't see a reason why we should introduce >> another driver for the same IP if the driver works for both SoCs. >> >> Michael >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
