RE: [GIT PULL] exynos-drm-next
Hi Dave and Daniel, There was my mistake. One patch not related to Exynos was included to this PR. I will resend it again. Thanks, Inki Dae > -Original Message- > From: Inki Dae On Behalf Of Inki Dae > Sent: Friday, September 6, 2024 6:14 PM > To: airl...@linux.ie; dan...@ffwll.ch > Cc: dri-devel@lists.freedesktop.org; linux-samsung-...@vger.kernel.org > Subject: [GIT PULL] exynos-drm-next > > Hi Dave and Daniel, > >Just three cleanups and one fixup. > > Please kindly let me know if there is any problem. > > Thanks, > > > The following changes since commit > b1aa0491fad27f030c94ed42c873c3f46f5e7364: > > drm/xe: Fix merge fails related to display runtime PM (2024-09-02 > 14:14:07 +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.12 > > for you to fetch changes up to 94ebc3d3235c5c516f67315059ce657e5090e94b: > > drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind() (2024-09- > 06 16:08:30 +0900) > > > Three cleanups > - Drop stale exynos file pattern from MAINTAINERS file > The old "exynos" directory is removed from MAINTAINERS as Samsung Exynos > display bindings have been relocated. This resolves a warning > from get_maintainers.pl about no files matching the outdated directory. > > - Constify struct exynos_drm_ipp_funcs > By making struct exynos_drm_ipp_funcs constant, the patch enhances > security > by moving the structure to a read-only section of memory. > This change results in a slight reduction in the data section size. > > - Remove unnecessary code > The function exynos_atomic_commit is removed as it became redundant > after a previous update. This cleans up the code and eliminates > unused function declarations. > > One fixup > - Fix wrong assignment in gsc_bind() > A double assignment in gsc_bind() was flagged by the cocci tool and > corrected to fix an incorrect assignment, addressing a potential issue > introduced in a prior commit. > > > Christophe JAILLET (1): > drm/exynos: Constify struct exynos_drm_ipp_funcs > > Krzysztof Kozlowski (1): > dt-bindings: MAINTAINERS: drop stale exynos file pattern > > Kwanghoon Son (1): > drm/exynos: Remove unnecessary code > > Simona Vetter (1): > MAINATINERS: update drm maintainer contacts > > Yuesong Li (1): > drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind() > > .mailmap | 4 > Documentation/gpu/introduction.rst | 10 - > Documentation/gpu/todo.rst | 34 +++-- > - > MAINTAINERS| 7 +++--- > drivers/gpu/drm/exynos/exynos_drm_drv.h| 4 > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_gsc.c| 4 ++-- > drivers/gpu/drm/exynos/exynos_drm_scaler.c | 2 +- > 8 files changed, 33 insertions(+), 34 deletions(-)
Re: [GIT PULL] exynos-drm-next
On Wed, Jul 03, 2024 at 04:59:12PM +0900, Inki Dae wrote: > Hi Dave and Daniel, > >Just three cleanup patches to Exynos Virtual Display driver >for improved management. > > Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > > The following changes since commit fb625bf6187d97c3cd28d680b14bf80f84207e5a: > > Merge tag 'drm-habanalabs-next-2024-06-23' of > https://github.com/HabanaAI/drivers.accel.habanalabs.kernel into drm-next > (2024-06-28 09:41:04 +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.11 > > for you to fetch changes up to 2210093478443cd57cff5950379fec31ee8a5f79: > > drm/exynos/vidi: convert to struct drm_edid (2024-07-03 13:00:16 +0900) Pulled, thanks. -Sima > > > Some cleanups to Exynos Virtual Display driver > - Use drm_edid_duplicate() instead of kmemdup(). > - Replace existing EDID handling with struct drm_edid functions > for improved management. > - Keep an allocated raw_edid or NULL and handle fake_edid_info in get_modes(). > > > Inki Dae (1): > Merge tag 'exynos-drm-fixes-for-v6.10-rc4' of > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into > exynos-drm-next > > Jani Nikula (4): > drm/exynos/vidi: fix memory leak in .get_modes() > drm/exynos/vidi: use drm_edid_duplicate() > drm/exynos/vidi: simplify fake edid handling > drm/exynos/vidi: convert to struct drm_edid > > Krzysztof Kozlowski (1): > drm/exynos: dp: drop driver owner initialization > > Marek Szyprowski (1): > drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID > found > > drivers/gpu/drm/exynos/exynos_dp.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 83 > ++-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++- > 3 files changed, 42 insertions(+), 49 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
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
RE: [GIT PULL] exynos-drm-next
> -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 > > > > 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_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 + > > driver
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 > > 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 > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [GIT PULL] exynos-drm-next
Hi Dave, 20. 3. 18. 오전 11:17에 Dave Airlie 이(가) 쓴 글: > This seems to contain a exynos drm fixes backmerge, please don't do > that without a headsup. > > Can you send one without that or do you need a fixes backmerge, if so > please request me to do that first, then rebase this and send it. Sorry for confusing you. Dropped the backmerge from exynos drm fixes and pushed it again. Please let me know if there is any problem. Thanks, Inki Dae > > Dave. > > On Mon, 16 Mar 2020 at 11:04, Inki Dae wrote: >> >> Just two cleanups - one is to mask encoder bitmask using >> drm_encoder_mask(), and other is to use mode->clock >> instead of calculating it again. >> >> Please kindly let me know if there is any problem. >> >> Thanks, >> Inki Dae >> >> The following changes since commit 69ddce0970d9d1de63bed9c24eefa0814db29a5a: >> >> Merge tag 'amd-drm-next-5.7-2020-03-10' of >> git://people.freedesktop.org/~agd5f/linux into drm-next (2020-03-13 09:09:11 >> +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.7 >> >> for you to fetch changes up to 0c9a609ca444298e438ee9c6daaf53c14277f1ad: >> >> drm/exynos: Use mode->clock instead of reverse calculating it from the >> vrefresh (2020-03-16 09:50:28 +0900) >> >> >> Two cleanups >> . Replace the hand rolled encoder bitmask thing with drm_encoder_mask() >> . Use mode->clock instead of reverse calculating it from the vrefresh >> >> >> Inki Dae (1): >> Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of >> git://git.kernel.org/.../daeinki/drm-exynos into exynos-drm-next >> >> Marek Szyprowski (1): >> drm/exynos: Fix cleanup of IOMMU related objects >> >> Ville Syrjälä (2): >> drm/exynos: Use drm_encoder_mask() >> drm/exynos: Use mode->clock instead of reverse calculating it from the >> vrefresh >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 --- >> drivers/gpu/drm/exynos/exynos_drm_dma.c | 28 >> ++- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 -- >> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +++-- >> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 -- >> drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-- >> 12 files changed, 56 insertions(+), 33 deletions(-) >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://protect2.fireeye.com/url?k=2f99e96f-720f5018-2f986220-0cc47a312ab0-6a58a038adb2e152&u=https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
This seems to contain a exynos drm fixes backmerge, please don't do that without a headsup. Can you send one without that or do you need a fixes backmerge, if so please request me to do that first, then rebase this and send it. Dave. On Mon, 16 Mar 2020 at 11:04, Inki Dae wrote: > > Just two cleanups - one is to mask encoder bitmask using > drm_encoder_mask(), and other is to use mode->clock > instead of calculating it again. > > Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit 69ddce0970d9d1de63bed9c24eefa0814db29a5a: > > Merge tag 'amd-drm-next-5.7-2020-03-10' of > git://people.freedesktop.org/~agd5f/linux into drm-next (2020-03-13 09:09:11 > +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.7 > > for you to fetch changes up to 0c9a609ca444298e438ee9c6daaf53c14277f1ad: > > drm/exynos: Use mode->clock instead of reverse calculating it from the > vrefresh (2020-03-16 09:50:28 +0900) > > > Two cleanups > . Replace the hand rolled encoder bitmask thing with drm_encoder_mask() > . Use mode->clock instead of reverse calculating it from the vrefresh > > > Inki Dae (1): > Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of > git://git.kernel.org/.../daeinki/drm-exynos into exynos-drm-next > > Marek Szyprowski (1): > drm/exynos: Fix cleanup of IOMMU related objects > > Ville Syrjälä (2): > drm/exynos: Use drm_encoder_mask() > drm/exynos: Use mode->clock instead of reverse calculating it from the > vrefresh > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +++-- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 --- > drivers/gpu/drm/exynos/exynos_drm_dma.c | 28 > ++- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 -- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +++-- > drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 -- > drivers/gpu/drm/exynos/exynos_mixer.c | 7 +-- > 12 files changed, 56 insertions(+), 33 deletions(-) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Dave, 19. 4. 24. 오전 11:03에 Dave Airlie 이(가) 쓴 글: > Hi Inki, > CC [M] drivers/gpu/drm/exynos/exynos_drm_scaler.o > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c: > In function ‘rotator_unbind’: > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21: > warning: unused variable ‘drm_dev’ [-Wunused-variable] > struct drm_device *drm_dev = data; > ^~~ > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c: > In function ‘scaler_unbind’: > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:472:21: > warning: unused variable ‘drm_dev’ [-Wunused-variable] > struct drm_device *drm_dev = data; > ^~~ > LD [M] drivers/gpu/drm/exynos/exynosdrm.o > > are those new? please fix and resent the pull > Sorry for this. I missed to remove them with some cleanup. Will resend the pull. Thanks, Inki Dae > Dave. > > On Mon, 22 Apr 2019 at 19:50, Inki Dae wrote: >> >> Hi Dave, >> >>Just log cleanup patches of Exynos KMS and DMA drivers >>including one trivial style fixup. >> >>Please kinkdly let me know if there is any problem. >> >> >> Thanks, >> Inki Dae >> >> >> The following changes since commit dbb92471674a48892f5e50779425e03388073ab9: >> >> Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 >> 06:46: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.2 >> >> for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8: >> >> drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900) >> >> >> Log cleanups >> - Correct the use of log macro in error case. >> - Drop unnecessary messages. >> - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG. >> - Print out debug messages with correct device name in vidi and ipp drivers. >> >> One trivial cleanup >> - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver. >> >> >> Inki Dae (6): >> drm/fimd: use DRM_ERROR instead of DRM_INFO in error case >> drm/exynos: remove unnecessary messages >> drm/exynos: use DRM_DEV_ERROR to print out error message >> drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro >> drm/vidi: replace platform_device pointer with device one >> drm/ipp: clean up debug messages >> >> Seung-Woo Kim (1): >> drm/exynos: g2d: remove style error >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +- >> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++ >> drivers/gpu/drm/exynos/exynos_dp.c| 9 ++- >> drivers/gpu/drm/exynos/exynos_drm_dma.c | 2 +- >> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ++- >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +- >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 ++- >> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 --- >> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 97 >> ++- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 48 +++-- >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 51 +++--- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 +- >> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 72 ++-- >> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 71 >> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 9 +-- >> drivers/gpu/drm/exynos/exynos_drm_mic.c | 29 >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++-- >> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +- >> drivers/gpu/drm/exynos/exynos_drm_scaler.c| 5 +- >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -- >> drivers/gpu/drm/exynos/exynos_hdmi.c | 75 - >> drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++- >> 22 files changed, 400 insertions(+), 298 deletions(-) >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Inki, CC [M] drivers/gpu/drm/exynos/exynos_drm_scaler.o /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c: In function ‘rotator_unbind’: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21: warning: unused variable ‘drm_dev’ [-Wunused-variable] struct drm_device *drm_dev = data; ^~~ /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c: In function ‘scaler_unbind’: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:472:21: warning: unused variable ‘drm_dev’ [-Wunused-variable] struct drm_device *drm_dev = data; ^~~ LD [M] drivers/gpu/drm/exynos/exynosdrm.o are those new? please fix and resent the pull Dave. On Mon, 22 Apr 2019 at 19:50, Inki Dae wrote: > > Hi Dave, > >Just log cleanup patches of Exynos KMS and DMA drivers >including one trivial style fixup. > >Please kinkdly let me know if there is any problem. > > > Thanks, > Inki Dae > > > The following changes since commit dbb92471674a48892f5e50779425e03388073ab9: > > Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 > 06:46: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.2 > > for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8: > > drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900) > > > Log cleanups > - Correct the use of log macro in error case. > - Drop unnecessary messages. > - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG. > - Print out debug messages with correct device name in vidi and ipp drivers. > > One trivial cleanup > - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver. > > > Inki Dae (6): > drm/fimd: use DRM_ERROR instead of DRM_INFO in error case > drm/exynos: remove unnecessary messages > drm/exynos: use DRM_DEV_ERROR to print out error message > drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro > drm/vidi: replace platform_device pointer with device one > drm/ipp: clean up debug messages > > Seung-Woo Kim (1): > drm/exynos: g2d: remove style error > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++ > drivers/gpu/drm/exynos/exynos_dp.c| 9 ++- > drivers/gpu/drm/exynos/exynos_drm_dma.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ++- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 ++- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 --- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 97 > ++- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 48 +++-- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 51 +++--- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 +- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 72 ++-- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 71 > drivers/gpu/drm/exynos/exynos_drm_ipp.h | 9 +-- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 29 > drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++-- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +- > drivers/gpu/drm/exynos/exynos_drm_scaler.c| 5 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -- > drivers/gpu/drm/exynos/exynos_hdmi.c | 75 - > drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++- > 22 files changed, 400 insertions(+), 298 deletions(-) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On Tue, Nov 28, 2017 at 02:45:49PM +0100, Marek Szyprowski wrote:
> Hi Daniel,
>
> On 2017-11-20 08:33, Daniel Vetter wrote:
> > On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
> > > 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
> > > > On 26 October 2017 at 11:37, Inki Dae wrote:
> > > > > Improving Exynos DRM HDMI and Mixer drivers and also adding
> > > > > HDMI audio support.
> > > > >
> > > > > Please kindly let me know if there is any problem.
> > > > >
> > > > > Ps. we are reviewing IPP v2 driver[1] which controls post
> > > > > processor devices
> > > > > such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to
> > > > > request
> > > > > git pull one more time after review.
> > > > I dropped the ball a bit here, I do think the second pull with IPP is
> > > > probably a bit late,
> > > > I think I'd like more assurance that the UAPI for IPP is to be used in
> > > > some upstream
> > > > shipping project (forks of mpv not withstanding, unless this fork
> > > > ships in some distro
> > > > or product).
> > > I also commented same thing internally to author - Marek - of IPP v2 but
> > > I thought existing one is really ugly thing so may be better to change it
> > > as soon as possible before other users use this one.
> > > Anyway, we will merge user space for IPP v2 to libdrm first, and then
> > > Linux platform. I hope IPPv2 would be merged as soon as possible in next
> > > turn.
> > Beyond what Daniel said we unfortunately don't have time machines, so
> > fixing bad uapi isn't really possible. The problem is that even if you
> > create ippv2, then people can still use ippv1, and it needs to keep
> > working (almost) forever. So once a bad uapi is in, it's in, and there's
> > no good reason to add more uapi (since in 2 years you might again realize
> > it's not a good idea) to "fix" that. You can't fix bad uapi.
> >
> > That's why we have all these rules to make sure as little bad uapi as
> > possible lands, since the cost is so bad.
> >
> > So yeah unless you have new hw that needs it, or there's another clear
> > need (performance, features), you're stuck with ippv1. "It's cleaner" is
> > not a good reason to rev uapi, since our experience with all the uapi in
> > drm clearly shows we can't predict the future :-)
>
> I generally agree that UAPI interface has to be stable and well designed.
>
> There are however some 'features' IPPv1 uapi that really allows us to
> obsolete it:
>
> 1. IPP API can be optional in Exynos DRM, so userspace should not rely that
> it is always available and should have a software fallback in case it is not
> available.
>
> 2. The only mode which was initially semi-working was memory-to-memory. The
> remaining modes (lcd-writeback and output) were never operational (both in
> mainline and even vendor kernels).
>
> 3. IPP mainline uapi compatibility for memory-to-memory got broken very
> early by commit 083500baefd5f4c215a5a93aef2492c1aa775828 ("drm: remove
> DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main
> feature which made this api somehow useful on Exynos platforms (video codec
> that time produced only tiled frames, to implement xvideo or any other
> video overlay, one has to detile them for proper display).
>
> 4. Broken drivers. Especially once support for IOMMU has been added, it
> revealed that drivers don't configure DMA operations properly and in many
> cases operate outside the provided buffers trashing memory around.
>
> 5. Need for external patches. Although IPP uapi has been used in some
> vendor kernels, but in such cases there were additional patches applied
> (like reverting mentioned 083500baefd5 patch) what means that those
> userspace apps which might use it, still won't work with the mainline
> version.
>
> Right, as you already said we don't have time machines, so we cannot change
> it, but IPP extension should never have been merged to mainline in that
> form.
>
> We can however obsolete it now as it is really non-functional and frankly
> speaking dead-code. If you agree with the above than at least the first
> patch can be merged, which clearly marks that Exynos IPP is broken and
> ever really functional. I bet no one will complain. Then we can continue
> the discussion about IPPv2 uapi/patches.
Ok, if what's currently is upstream is indeed entirely non-functional then
I think we can make a case for ippv2. But imo we should then also first
rip out ippv1. Which given that it's optional, and apparently your
userspace can cope, should be doable without causing any big trouble.
But now that you explained why ippv1 is a hopeless patient that won't make
it, why is ippv2 better? Do we have solid testcases for this stuff now? Is
the userspace production quality or still kinda just a tech demo?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.free
Re: [GIT PULL] exynos-drm-next
Hi Daniel, 2017년 11월 20일 16:33에 Daniel Vetter 이(가) 쓴 글: > On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote: >> Hi Dave, >> >> 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글: >>> On 26 October 2017 at 11:37, Inki Dae wrote: Hi Dave, Improving Exynos DRM HDMI and Mixer drivers and also adding HDMI audio support. Please kindly let me know if there is any problem. Ps. we are reviewing IPP v2 driver[1] which controls post processor devices such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request git pull one more time after review. >>> >>> Hi Inki, >>> >>> I dropped the ball a bit here, I do think the second pull with IPP is >>> probably a bit late, >>> I think I'd like more assurance that the UAPI for IPP is to be used in >>> some upstream >>> shipping project (forks of mpv not withstanding, unless this fork >>> ships in some distro >>> or product). >> >> I also commented same thing internally to author - Marek - of IPP v2 but I >> thought existing one is really ugly thing so may be better to change it as >> soon as possible before other users use this one. >> Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux >> platform. I hope IPPv2 would be merged as soon as possible in next turn. > > Beyond what Daniel said we unfortunately don't have time machines, so > fixing bad uapi isn't really possible. The problem is that even if you > create ippv2, then people can still use ippv1, and it needs to keep > working (almost) forever. So once a bad uapi is in, it's in, and there's I'd like to make sure one thing. Yes, there may be some users who still use ippv1 but we should consider them even they aren't 'real user'? I.e., some test applications used internally. As long as I know, only 'real user' who uses ippv1 would be me and my team. If we have to consider all users including in-house test applications then we may need to keep UAPI v1 and only change its implementation. Thanks, Inki Dae > no good reason to add more uapi (since in 2 years you might again realize > it's not a good idea) to "fix" that. You can't fix bad uapi. > > That's why we have all these rules to make sure as little bad uapi as > possible lands, since the cost is so bad. > > So yeah unless you have new hw that needs it, or there's another clear > need (performance, features), you're stuck with ippv1. "It's cleaner" is > not a good reason to rev uapi, since our experience with all the uapi in > drm clearly shows we can't predict the future :-) > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Daniel,
On 2017-11-20 08:33, Daniel Vetter wrote:
On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
On 26 October 2017 at 11:37, Inki Dae wrote:
Improving Exynos DRM HDMI and Mixer drivers and also adding
HDMI audio support.
Please kindly let me know if there is any problem.
Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
git pull one more time after review.
I dropped the ball a bit here, I do think the second pull with IPP is
probably a bit late,
I think I'd like more assurance that the UAPI for IPP is to be used in
some upstream
shipping project (forks of mpv not withstanding, unless this fork
ships in some distro
or product).
I also commented same thing internally to author - Marek - of IPP v2 but I
thought existing one is really ugly thing so may be better to change it as soon
as possible before other users use this one.
Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux
platform. I hope IPPv2 would be merged as soon as possible in next turn.
Beyond what Daniel said we unfortunately don't have time machines, so
fixing bad uapi isn't really possible. The problem is that even if you
create ippv2, then people can still use ippv1, and it needs to keep
working (almost) forever. So once a bad uapi is in, it's in, and there's
no good reason to add more uapi (since in 2 years you might again realize
it's not a good idea) to "fix" that. You can't fix bad uapi.
That's why we have all these rules to make sure as little bad uapi as
possible lands, since the cost is so bad.
So yeah unless you have new hw that needs it, or there's another clear
need (performance, features), you're stuck with ippv1. "It's cleaner" is
not a good reason to rev uapi, since our experience with all the uapi in
drm clearly shows we can't predict the future :-)
I generally agree that UAPI interface has to be stable and well designed.
There are however some 'features' IPPv1 uapi that really allows us to
obsolete it:
1. IPP API can be optional in Exynos DRM, so userspace should not rely that
it is always available and should have a software fallback in case it is not
available.
2. The only mode which was initially semi-working was memory-to-memory. The
remaining modes (lcd-writeback and output) were never operational (both in
mainline and even vendor kernels).
3. IPP mainline uapi compatibility for memory-to-memory got broken very
early by commit 083500baefd5f4c215a5a93aef2492c1aa775828 ("drm: remove
DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main
feature which made this api somehow useful on Exynos platforms (video codec
that time produced only tiled frames, to implement xvideo or any other
video overlay, one has to detile them for proper display).
4. Broken drivers. Especially once support for IOMMU has been added, it
revealed that drivers don't configure DMA operations properly and in many
cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP uapi has been used in some
vendor kernels, but in such cases there were additional patches applied
(like reverting mentioned 083500baefd5 patch) what means that those
userspace apps which might use it, still won't work with the mainline
version.
Right, as you already said we don't have time machines, so we cannot change
it, but IPP extension should never have been merged to mainline in that
form.
We can however obsolete it now as it is really non-functional and frankly
speaking dead-code. If you agree with the above than at least the first
patch can be merged, which clearly marks that Exynos IPP is broken and
ever really functional. I bet no one will complain. Then we can continue
the discussion about IPPv2 uapi/patches.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote: > Hi Dave, > > 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글: > > On 26 October 2017 at 11:37, Inki Dae wrote: > >> Hi Dave, > >> > >>Improving Exynos DRM HDMI and Mixer drivers and also adding > >>HDMI audio support. > >> > >>Please kindly let me know if there is any problem. > >> > >>Ps. we are reviewing IPP v2 driver[1] which controls post processor > >> devices > >>such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to > >> request > >>git pull one more time after review. > > > > Hi Inki, > > > > I dropped the ball a bit here, I do think the second pull with IPP is > > probably a bit late, > > I think I'd like more assurance that the UAPI for IPP is to be used in > > some upstream > > shipping project (forks of mpv not withstanding, unless this fork > > ships in some distro > > or product). > > I also commented same thing internally to author - Marek - of IPP v2 but I > thought existing one is really ugly thing so may be better to change it as > soon as possible before other users use this one. > Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux > platform. I hope IPPv2 would be merged as soon as possible in next turn. Beyond what Daniel said we unfortunately don't have time machines, so fixing bad uapi isn't really possible. The problem is that even if you create ippv2, then people can still use ippv1, and it needs to keep working (almost) forever. So once a bad uapi is in, it's in, and there's no good reason to add more uapi (since in 2 years you might again realize it's not a good idea) to "fix" that. You can't fix bad uapi. That's why we have all these rules to make sure as little bad uapi as possible lands, since the cost is so bad. So yeah unless you have new hw that needs it, or there's another clear need (performance, features), you're stuck with ippv1. "It's cleaner" is not a good reason to rev uapi, since our experience with all the uapi in drm clearly shows we can't predict the future :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Daniel, 2017년 11월 15일 19:27에 Daniel Stone 이(가) 쓴 글: > Hi Inki, > > On 15 November 2017 at 01:26, Inki Dae wrote: >> 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글: >>> On 26 October 2017 at 11:37, Inki Dae wrote: Ps. we are reviewing IPP v2 driver[1] which controls post processor devices such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request git pull one more time after review. >>> >>> I dropped the ball a bit here, I do think the second pull with IPP is >>> probably a bit late, >>> I think I'd like more assurance that the UAPI for IPP is to be used in >>> some upstream >>> shipping project (forks of mpv not withstanding, unless this fork >>> ships in some distro >>> or product). >> >> I also commented same thing internally to author - Marek - of IPP v2 but I >> thought existing one is really ugly thing so may be better to change it as >> soon as possible before other users use this one. >> Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux >> platform. I hope IPPv2 would be merged as soon as possible in next turn. > > This is putting the cart before the horse a little bit. This is the > process for merging new DRM API: > > Prepare the kernel and libdrm/etc patches exposing the new API, and > also develop a _real_ user for it. Using IPP as an example, an > acceptable userspace would be VLC, Kodi, Weston, Xorg, or similar. > libdrm sample clients are explicitly not enough for this. > > Once this is done, you should get review/ack for all of these. The > kernel code and API should have review for good API (see for example > Daniel Vetter's 'botching up ioctls' documentation) and code, and the > userspace (VLC/Kodi/...) should have review for both code correctness > as well as an explicit check from the userspace side that they feel it > is good API which works for them. If the work just exists in a fork > which has not got real upstream review, this is also not enough. > > When all parts have review, you can merge the new kernel API with a > pointer to the userspace review, explicitly stating that they feel it > is acceptable. Once the kernel code has landed in a non-rebasing tree > (one which Dave will be sending as a pull), libdrm code can be merged, > and then the userspace code can finally be merged. I know that. Before requesting git-pull I commented like below to the author, "I think other maintainer will require real user space - not thing like libdrm - which uses new ABI. The solution I think would be to apply the new ABI to tdm exynos backend of Tizen platform below, https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtdm-exynos.git;a=blob;f=src/tdm_exynos_pp.c;h=db20e6f226d313672d1d468e06d80526ea30121c;hb=refs/heads/tizen"; Anyway, Linux platform I mentioned is _real_ user, Tizen[1], for it. Sorry about it. I didn't comment exactly what is the Linux platform. And thanks for explanation. [1] https://www.tizen.org/ Thanks, Inki Dae > > Cheers, > Daniel > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Inki, On 15 November 2017 at 01:26, Inki Dae wrote: > 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글: >> On 26 October 2017 at 11:37, Inki Dae wrote: >>>Ps. we are reviewing IPP v2 driver[1] which controls post processor >>> devices >>>such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request >>>git pull one more time after review. >> >> I dropped the ball a bit here, I do think the second pull with IPP is >> probably a bit late, >> I think I'd like more assurance that the UAPI for IPP is to be used in >> some upstream >> shipping project (forks of mpv not withstanding, unless this fork >> ships in some distro >> or product). > > I also commented same thing internally to author - Marek - of IPP v2 but I > thought existing one is really ugly thing so may be better to change it as > soon as possible before other users use this one. > Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux > platform. I hope IPPv2 would be merged as soon as possible in next turn. This is putting the cart before the horse a little bit. This is the process for merging new DRM API: Prepare the kernel and libdrm/etc patches exposing the new API, and also develop a _real_ user for it. Using IPP as an example, an acceptable userspace would be VLC, Kodi, Weston, Xorg, or similar. libdrm sample clients are explicitly not enough for this. Once this is done, you should get review/ack for all of these. The kernel code and API should have review for good API (see for example Daniel Vetter's 'botching up ioctls' documentation) and code, and the userspace (VLC/Kodi/...) should have review for both code correctness as well as an explicit check from the userspace side that they feel it is good API which works for them. If the work just exists in a fork which has not got real upstream review, this is also not enough. When all parts have review, you can merge the new kernel API with a pointer to the userspace review, explicitly stating that they feel it is acceptable. Once the kernel code has landed in a non-rebasing tree (one which Dave will be sending as a pull), libdrm code can be merged, and then the userspace code can finally be merged. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Dave, 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글: > On 26 October 2017 at 11:37, Inki Dae wrote: >> Hi Dave, >> >>Improving Exynos DRM HDMI and Mixer drivers and also adding >>HDMI audio support. >> >>Please kindly let me know if there is any problem. >> >>Ps. we are reviewing IPP v2 driver[1] which controls post processor >> devices >>such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request >>git pull one more time after review. > > Hi Inki, > > I dropped the ball a bit here, I do think the second pull with IPP is > probably a bit late, > I think I'd like more assurance that the UAPI for IPP is to be used in > some upstream > shipping project (forks of mpv not withstanding, unless this fork > ships in some distro > or product). I also commented same thing internally to author - Marek - of IPP v2 but I thought existing one is really ugly thing so may be better to change it as soon as possible before other users use this one. Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux platform. I hope IPPv2 would be merged as soon as possible in next turn. Thanks, Inki Dae > > I unfortunately forgot to pull this one, I've rectified that and it is > now in drm-next. > > Dave. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On 26 October 2017 at 11:37, Inki Dae wrote: > Hi Dave, > >Improving Exynos DRM HDMI and Mixer drivers and also adding >HDMI audio support. > >Please kindly let me know if there is any problem. > >Ps. we are reviewing IPP v2 driver[1] which controls post processor devices >such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request >git pull one more time after review. Hi Inki, I dropped the ball a bit here, I do think the second pull with IPP is probably a bit late, I think I'd like more assurance that the UAPI for IPP is to be used in some upstream shipping project (forks of mpv not withstanding, unless this fork ships in some distro or product). I unfortunately forgot to pull this one, I've rectified that and it is now in drm-next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Dave, 2017년 04월 19일 08:35에 Dave Airlie 이(가) 쓴 글: > On 18 April 2017 at 12:05, Inki Dae wrote: >> Hi Dave, >> >>Some improvements, fixups and cleanups to Exynos DRM. >> >>Ps. this pull-reuqest includes a merge tag from Krzysztof Kozlowski >>who is a Exynos SoC maintainer, which includes dt patches because >>these should be merged together with below one, >> drm/exynos: dsi: Fix the parse_dt function >> >>Please kindly let me know if there is any problem. > > Hi Inki, > > We closed the merge window at -rc6 for this release, due to some push > back from Linus, > > It was mentioned in a few mails on dri-devel, so I'm going to have to > leave this pull req > until the next merge, unless there is something in here that will break badly. Sorry for late. I was in a hurry but some review had been delayed. There is one patch which should be merged with Krzysztof's tree. Without this patch dt binding of Exynos drm will be broken. Almost patches of exynos-drm-next branch are fixup and cleanup so I will request pull to -fixes, maybe v4.12-rc1 in proper time again. Thanks, Inki Dae > > Dave. > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On Tue, Apr 18, 2017 at 4:30 AM, Inki Dae wrote: > > > 2017년 04월 18일 11:21에 Andi Shyti 이(가) 쓴 글: >> Hi Inki, >> >>> Andi Shyti (2): >>> arm64: dts: exynos: Enable ir-spi in the TM2 and TM2E boards >>> arm64: dts: exynos: Add stmfts touchscreen node for TM2 and TM2E >> >> weren't these patches taken already by Krzysztof? They are >> already in -next > > I know a merge tag would make one not to be merged if other is already merged. Yes, it is expected. They come from merging my branch as we requested. The commits are exactly the same as in my tree (same SHA) so everything will end up fine. The only thing here we missed here is merging the Hoegeun's patches for arm. But well... it happens. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Inki, > Andi Shyti (2): > arm64: dts: exynos: Enable ir-spi in the TM2 and TM2E boards > arm64: dts: exynos: Add stmfts touchscreen node for TM2 and TM2E weren't these patches taken already by Krzysztof? They are already in -next Andi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On 18 April 2017 at 12:05, Inki Dae wrote: > Hi Dave, > >Some improvements, fixups and cleanups to Exynos DRM. > >Ps. this pull-reuqest includes a merge tag from Krzysztof Kozlowski >who is a Exynos SoC maintainer, which includes dt patches because >these should be merged together with below one, > drm/exynos: dsi: Fix the parse_dt function > >Please kindly let me know if there is any problem. Hi Inki, We closed the merge window at -rc6 for this release, due to some push back from Linus, It was mentioned in a few mails on dri-devel, so I'm going to have to leave this pull req until the next merge, unless there is something in here that will break badly. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
2017년 04월 18일 11:21에 Andi Shyti 이(가) 쓴 글: > Hi Inki, > >> Andi Shyti (2): >> arm64: dts: exynos: Enable ir-spi in the TM2 and TM2E boards >> arm64: dts: exynos: Add stmfts touchscreen node for TM2 and TM2E > > weren't these patches taken already by Krzysztof? They are > already in -next I know a merge tag would make one not to be merged if other is already merged. Thanks, Inki Dae > > Andi > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > . > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
2017년 04월 18일 11:05에 Inki Dae 이(가) 쓴 글: > Hi Dave, > >Some improvements, fixups and cleanups to Exynos DRM. > >Ps. this pull-reuqest includes a merge tag from Krzysztof Kozlowski >who is a Exynos SoC maintainer, which includes dt patches because >these should be merged together with below one, > drm/exynos: dsi: Fix the parse_dt function > >Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit ab6eb211b07a42a6346e284056422fd9a8576a99: > > Merge tag 'drm/panel/for-4.12-rc1' of > git://anongit.freedesktop.org/tegra/linux into drm-next (2017-04-13 06:17:40 > +1000) I'm sorry. I missed to put a tag name here. Below is a merge tag. git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v4.12 Thanks, Inki Dae > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > exynos-drm-next > > for you to fetch changes up to ad1a14690ae7114e5230deba27cdbbe42c69a813: > > drm/exynos/decon5433: remove useless check (2017-04-18 10:28:50 +0900) > > > Summary: > - Fix dt binding of MIPI-DSI driver > - Rework vblank handling > . This patch series adds frame counter callback and removes > unnecessary pipe relevnt fields and simplifies event handling. > - Implement and fix sw-trigger relevant code > . This patch moves TE relevant code from Panel and HDMI to DECON driver > to fix a race between interrupt handlers and DECON disable, > and to fix timeout issue at wait-for-vblank. > . It removes unnecessary flags and check code specific to Exynos driver. > > > Andi Shyti (2): > arm64: dts: exynos: Enable ir-spi in the TM2 and TM2E boards > arm64: dts: exynos: Add stmfts touchscreen node for TM2 and TM2E > > Andrzej Hajda (21): > drm/exynos: simplify completion event handling > drm/exynos/decon5433: implement frame counter > drm/exynos: kill exynos_drm_crtc::pipe > drm/exynos: kill exynos_drm_private::pipe > drm/exynos: set plane possible_crtcs in exynos_plane_init > drm/exynos: kill pipe field from drivers contexts > drm/exynos: kill mode_set_nofb callback > drm/exynos/decon5433: kill DECON_UPDATE workaround > drm/exynos/decon5433: kill BIT_IRQS_ENABLED > drm/exynos/decon5433: simplify shadow protect code > drm/exynos/hdmi: fix pipeline disable order > drm/exynos/dsi: fix bridge_node DT parsing > drm/exynos/decon5433: always do sw-trigger when vblanks enabled > dt-bindings: exynos5433-decon: fix interrupts bindings > dt-bindings: exynos5433-decon: add TE interrupt binding > drm/exynos/decon5433: move TE handling to DECON > drm/exynos/decon5433: kill BIT_IRQS_ENABLED flag > drm/exynos/decon5433: kill BIT_CLKS_ENABLED flag > drm/exynos/decon5433: kill BIT_WIN_UPDATED flag > drm/exynos/decon5433: kill BIT_SUSPENDED flag > drm/exynos/decon5433: remove useless check > > Daniel Vetter (1): > drm/exynos: Merge pre/postclose hooks > > Hoegeun Kwon (2): > arm64: dts: exynos: Add the burst and esc clock frequency properties to > DSI node > drm/exynos: dsi: Fix the parse_dt function > > Hyungwon Hwang (1): > arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board > > Inki Dae (2): > Merge tag 'samsung-dt64-clock-dsi-property-4.12' of > gitolite.kernel.org:/.../krzk/linux into exynos-drm-next > drm/exynos: clean up description of exynos_drm_crtc > > Tobias Jakobi (2): > drm/exynos: mixer: simplify mixer_cfg_rgb_fmt() > drm/exynos: mixer: document YCbCr magic numbers > > .../bindings/display/exynos/exynos5433-decon.txt | 13 +- > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 43 +++- > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 ++ > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 7 + > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 218 > + > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 19 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 50 +++-- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 - > drivers/gpu/drm/exynos/exynos_drm_drv.c| 8 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 24 +-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +-- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 5 +- > drivers/gpu/drm/exynos/exynos_drm_plane.h | 1 - > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 22 +-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +- > drivers/gpu/drm/exynos/exynos_mixer.c | 76 --- > drivers/gpu/drm/exynos/regs-mixer.h
Re: [GIT PULL] exynos-drm-next
Finally, Thierry gave comment and he wants the panel driver not to be merged yet. So removed the patch from exynos-drm-next tree. Thanks, Inki Dae 2017년 01월 31일 09:46에 Inki Dae 이(가) 쓴 글: > Hi Dave, > >adding runtime PM support to MIC driver, and including some >cleanups - especially using atomic helper functions >instead of specific ones - and fixups. > >In addition, it includes S6E3HA2 panel driver and its support. >The panel driver should go to mainline by Thierry. >However, there is no comment from him. Seems he is busy maybe. >I think we had review enough so I picked it up. > >And we have one patch series for UHD support which is under the review. >So I plan to have a pull request again as soon as finising the review. > >Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit a5b2b6ebf34b20e70a2bdb5214c371744e7fa260: > > drm/sti: Fix compilation failure for drm_framebuffer.pixel_format > (2017-01-27 12:54:15 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > exynos-drm-next > > for you to fetch changes up to 2473244a04edf5480770bd840c38546b800f839d: > > drm/panel: Add support for S6E3HA2 panel driver on TM2 board (2017-01-31 > 09:02:21 +0900) > > > Dan Carpenter (1): > drm/exynos: fix a timeout loop > > Daniel Vetter (1): > drm/exynos: Stop using drm_framebuffer_unregister_private > > Hoegeun Kwon (3): > drm/exynos: mic: Add mode_set callback function > drm/exynos: mic: Fix parse_dt function > drm/panel: Add support for S6E3HA2 panel driver on TM2 board > > Inki Dae (2): > drm/exynos: remove unnecessary codes > drm/exynos: use atomic helper commit > > Joonyoung Shim (1): > drm/exynos: g2d: prevent integer overflow in > > Marek Szyprowski (1): > drm/exynos: mic: Add runtime PM support > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 28 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 4 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 114 > drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 +- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 126 +++-- > drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- > drivers/gpu/drm/panel/Kconfig | 6 + > drivers/gpu/drm/panel/Makefile| 1 + > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 > ++ > 11 files changed, 892 insertions(+), 196 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Dave, Below is additional comments, The below patch has a dependency of Exynos drm driver's patch set so this pull requst includes this one. drm: hold event_lock while accessing vblank_event_list And in addition, below is patches merged to exynos-drm-next, drm/exynos: fix memory leak to EDID block drm/exynos: remove 'pages' and 'page_size' elements in exynos gem buffer drm: exynos: fix for loosing display mode header during mode adjustment drm/exynos: Unreference fb in exynos_disable_plane() And there are patches I missed like below and they are being reviewed now, drm: exynos: compose and send avi and aui info frames drm: get cea video id code for a given display mode And last, below is new modules for Exynos drm driver, drm/exynos: add ipp subsystem and each ipp drivers drm/exynos: add ipp subsystem drm/exynos: add fimc ipp driver drm/exynos: add rotator ipp driver drm/exynos: add gsc ipp driver but they didn't reviewed enough yet so may not be merged to -next this time. Thanks, Inki Dae 2012/11/20 Inki Dae > Hi Dave, > > This patch set adds iommu support, userptr feature to g2d, minor fixups > and code cleanups. > > And the iommu feature has dependency of the below patches related to > dma mapping framework. > For this, ccing DMA Mapping framework maintainer, Marek Szyprowski. > Marek, please give me ack. > common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute > ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS > attribute. > > This patch is used to allocate fully physically contiguous memory region. > > And now the below patch is being reviewed and it's going to be merged soon. > drm/exynos: remove 'pages' and 'page_size' elements in exynos gem > buffer > > And this includes also previous pull request to exynos-drm-fixes. > > If there is any problem, plese let me know. > > Thanks, > Inki Dae > > The following changes since commit > bf6f036848ab2151c2498f11cb7d31a52a95dd5c: > > drm/vmwgfx: Make vmw_dmabuf_unreference handle NULL objects (2012-11-20 > 16:19:59 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.gitexynos-drm-next > > Imre Deak (4): > drm/exynos: hold event_lock while accessing pageflip_event_list > drm/exynos: call drm_vblank_put for each queued flip event > drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock > drm: hold event_lock while accessing vblank_event_list > > Inki Dae (12): > drm/exynos: fix linux framebuffer address setting. > drm/exynos: remove unnecessary code. > drm/exynos: fix overlay updating issue > drm/exynos: add iommu support for exynos drm framework > drm/exynos: add iommu support to fimd driver > drm/exynos: add iommu support for hdmi driver > drm/exynos: add iommu support for g2d > drm/exynos: remove EXYNOS_BO_NONCONTIG type checking. > drm/exynos: add userptr feature for g2d module > drm/exynos: add vm_ops to specific gem mmaper > drm/exynos: release fb pended by page flip > drm/exynos: make sure that overlay data are updated > > Marek Szyprowski (2): > common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute > ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute > > Prathyush K (2): > drm/exynos: remove unnecessary sg_alloc_table call > drm/exynos: add exynos drm specific fb_mmap function > > Rahul Sharma (1): > drm: exynos: fix for mapping of dma buffers > > Sachin Kamat (1): > drm/exynos: Make exynos4/5_fimd_driver_data static > > Documentation/DMA-attributes.txt|9 + > arch/arm/mm/dma-mapping.c | 41 ++- > drivers/gpu/drm/drm_irq.c |3 + > drivers/gpu/drm/exynos/Kconfig |6 + > drivers/gpu/drm/exynos/Makefile |1 + > drivers/gpu/drm/exynos/exynos_drm_buf.c | 88 ++--- > drivers/gpu/drm/exynos/exynos_drm_crtc.c| 47 +++- > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 85 ++--- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 23 ++- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 49 +++- > drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 + > drivers/gpu/drm/exynos/exynos_drm_fb.c | 79 +- > drivers/gpu/drm/exynos/exynos_drm_fb.h |6 + > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 42 +++- > drivers/gpu/drm/exynos/exynos_drm_fimd.c| 33 +-- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 491 > +++ > drivers/gpu/drm/exynos/exynos_drm_gem.c | 446 > + > drivers/gpu/drm/exynos/exynos_drm_gem.h | 52 +++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.c| 15 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.h|1 + > drivers/gpu/drm/exyno
Re: [GIT PULL] exynos-drm-next
Hello, On 11/20/2012 8:35 AM, Inki Dae wrote: Hi Dave, This patch set adds iommu support, userptr feature to g2d, minor fixups and code cleanups. And the iommu feature has dependency of the below patches related to dma mapping framework. For this, ccing DMA Mapping framework maintainer, Marek Szyprowski. Marek, please give me ack. common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute. For the dma-mapping related changes: Acked-by: Marek Szyprowski This patch is used to allocate fully physically contiguous memory region. And now the below patch is being reviewed and it's going to be merged soon. drm/exynos: remove 'pages' and 'page_size' elements in exynos gem buffer And this includes also previous pull request to exynos-drm-fixes. If there is any problem, plese let me know. Thanks, Inki Dae The following changes since commit bf6f036848ab2151c2498f11cb7d31a52a95dd5c: drm/vmwgfx: Make vmw_dmabuf_unreference handle NULL objects (2012-11-20 16:19:59 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next Imre Deak (4): drm/exynos: hold event_lock while accessing pageflip_event_list drm/exynos: call drm_vblank_put for each queued flip event drm/exynos: fix lockdep for event_lock wrt. vbl_time_lock drm: hold event_lock while accessing vblank_event_list Inki Dae (12): drm/exynos: fix linux framebuffer address setting. drm/exynos: remove unnecessary code. drm/exynos: fix overlay updating issue drm/exynos: add iommu support for exynos drm framework drm/exynos: add iommu support to fimd driver drm/exynos: add iommu support for hdmi driver drm/exynos: add iommu support for g2d drm/exynos: remove EXYNOS_BO_NONCONTIG type checking. drm/exynos: add userptr feature for g2d module drm/exynos: add vm_ops to specific gem mmaper drm/exynos: release fb pended by page flip drm/exynos: make sure that overlay data are updated Marek Szyprowski (2): common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute Prathyush K (2): drm/exynos: remove unnecessary sg_alloc_table call drm/exynos: add exynos drm specific fb_mmap function Rahul Sharma (1): drm: exynos: fix for mapping of dma buffers Sachin Kamat (1): drm/exynos: Make exynos4/5_fimd_driver_data static Documentation/DMA-attributes.txt|9 + arch/arm/mm/dma-mapping.c | 41 ++- drivers/gpu/drm/drm_irq.c |3 + drivers/gpu/drm/exynos/Kconfig |6 + drivers/gpu/drm/exynos/Makefile |1 + drivers/gpu/drm/exynos/exynos_drm_buf.c | 88 ++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 47 +++- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 85 ++--- drivers/gpu/drm/exynos/exynos_drm_drv.c | 23 ++- drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 49 +++- drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 79 +- drivers/gpu/drm/exynos/exynos_drm_fb.h |6 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 42 +++- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 33 +-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 491 +++ drivers/gpu/drm/exynos/exynos_drm_gem.c | 446 + drivers/gpu/drm/exynos/exynos_drm_gem.h | 52 +++- drivers/gpu/drm/exynos/exynos_drm_hdmi.c| 15 + drivers/gpu/drm/exynos/exynos_drm_hdmi.h|1 + drivers/gpu/drm/exynos/exynos_drm_iommu.c | 150 drivers/gpu/drm/exynos/exynos_drm_iommu.h | 85 + drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 20 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 21 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 11 +- include/linux/dma-attrs.h |1 + include/uapi/drm/exynos_drm.h | 13 +- 29 files changed, 1371 insertions(+), 481 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
