Hi Dave,
This pull request includes comprehensive cleanups to HDMI part and several fixups, and revive a Exynos specific interface which was used to get fake offset, which is required for application using render node to access a gem memory. For userspace codes for the use of this interface, you can refer to below link, https://github.com/dofmind/libdrm/commit/5cc58d765c61b37a26372de9701f3ffe3a1...
We will post a patch for libdrm after this patch is merged to mainline.
In addition, this pull request includes also a defconfig patch which enables mixer driver as default. For this, I got already Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer.
Please kindly let me know if there is any problem.
Thanks, Inki Dae
The following changes since commit d7e1bc3f5e70c5a106606e33cfa4d413459611ba:
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next (2015-10-23 11:54:03 +1000)
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 01bdaac3d7febed08e1b257a9cbb07e04ba8ce4c:
ARM: exynos_defconfig: enable Exynos DRM Mixer driver (2015-10-28 15:18:31 +0900)
---------------------------------------------------------------- Andrzej Hajda (27): drm/exynos/hdmi: remove support for deprecated compatible drm/exynos/hdmi: use mappings for registers with IP dependent address drm/exynos/hdmi: move PLL stabilization check code to separate function drm/exynos/hdmi: simplify HDMI-PHY power sequence drm/exynos/hdmi: replace all writeb with writel drm/exynos/hdmi: fix removal order drm/exynos/hdmi: use optional regulator_get for hdmi-en drm/exynos/hdmi: use constant size array for regulators drm/exynos/hdmi: simplify clock re-parenting drm/exynos/hdmi: convert to gpiod API drm/exynos/hdmi: remove deprecated hdmi_resources structure drm/exynos/hdmi: convert container_of macro to inline function drm/exynos/hdmi: improve HDMI/ACR related code drm/exynos/hdmi: remove unused field drm/exynos/decon5433: add PCLK clock drm/exynos/decon5433: fix timing registers writes drm/exynos/decon5433: add function to set particular register bits drm/exynos/decon5433: merge different flag fields drm/exynos/decon5433: remove duplicated initialization drm/exynos/decon5433: add support for DECON-TV drm/exynos: add atomic_check callback to exynos_crtc drm/exynos/mixer: replace direct cross-driver call with drm mode validation drm/exynos: separate Mixer and HDMI drivers drm/exynos: abstract out common dependency drm/exynos: re-arrange Kconfig entries drm/exynos: simplify Kconfig component names ARM: exynos_defconfig: enable Exynos DRM Mixer driver
Gustavo Padovan (2): drm/exynos: add global macro for the default primary plane drm/exynos: add cursor plane support
Ingi Kim (1): drm/exynos: fix spelling errors
Joonyoung Shim (3): drm/exynos: fix to detach device of iommu drm/exynos: cleanup name of gem object for exynos_drm drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
Tomasz Stanislawski (1): drm: exynos: mixer: fix using usleep() in atomic context
arch/arm/configs/exynos_defconfig | 1 + drivers/gpu/drm/exynos/Kconfig | 75 ++-- drivers/gpu/drm/exynos/Makefile | 3 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 324 +++++++++-------- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 45 ++- drivers/gpu/drm/exynos/exynos_drm_fb.h | 5 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 53 +-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 248 +++++++------ drivers/gpu/drm/exynos/exynos_drm_gem.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 + drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 496 +++++++++----------------- drivers/gpu/drm/exynos/exynos_mixer.c | 17 +- drivers/gpu/drm/exynos/exynos_mixer.h | 20 -- drivers/gpu/drm/exynos/regs-hdmi.h | 33 +- include/uapi/drm/exynos_drm.h | 17 +- include/video/exynos5433_decon.h | 29 ++ 26 files changed, 703 insertions(+), 780 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h
Hi Inki,
On 28 October 2015 at 06:55, Inki Dae inki.dae@samsung.com wrote:
and revive a Exynos specific interface which was used to get fake offset, which is required for application using render node to access a gem memory. For userspace codes for the use of this interface, you can refer to below link, https://github.com/dofmind/libdrm/commit/5cc58d765c61b37a26372de9701f3ffe3a1...
We will post a patch for libdrm after this patch is merged to mainline.
Is there any real (non-libdrm) userspace for this? See Daniel Vetter's reply to the series here: 'In general we wait with merging new userspace ABI until that's really ready, since very often there's some corner cases that you just didn't think about in your toy demo compared to the real thing. Like how to manage buffer caches/reuse for apps that essentially run forever (like X server or a compositor).'
Probably my biggest concern is how well this operates with the proposed PREP/FINI patches. I would really love to see a real userspace which exercises both MAP and PREP/FINI: if that shows problems with this interface, then it means we have to carry this interface forever, _as well as_ a new cleaned-up one.
Cheers, Daniel
Hi Daniel,
2015년 10월 28일 19:15에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 06:55, Inki Dae inki.dae@samsung.com wrote:
and revive a Exynos specific interface which was used to get fake offset, which is required for application using render node to access a gem memory. For userspace codes for the use of this interface, you can refer to below link, https://github.com/dofmind/libdrm/commit/5cc58d765c61b37a26372de9701f3ffe3a1...
We will post a patch for libdrm after this patch is merged to mainline.
Is there any real (non-libdrm) userspace for this? See Daniel Vetter's reply to the series here: 'In general we wait with merging new userspace ABI until that's really ready, since very often there's some corner cases that you just didn't think about in your toy demo compared to the real thing. Like how to manage buffer caches/reuse for apps that essentially run forever (like X server or a compositor).'
Below link is a libdrm codes used by Tizen platform. https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=6e97...
In Tizen platform, there is a buffer manager called TBM(Tizem Buffer Manager), and this manager uses this new interface of libdrm.
Tizen platform can use window systems - wayland or X server - according to version. And the native systems use the TBM interfaces to manage gem buffer.
Probably my biggest concern is how well this operates with the proposed PREP/FINI patches. I would really love to see a real userspace which exercises both MAP and PREP/FINI: if that shows
Hmm... Daniel, seems there was your mislead. I will never merge such PREP/FINI interfaces for cache operation until these will be reviewed enough through real user. So this pull request doesn't include them. We are just planning to apply these interfaces to Tizen platform for more test.
Thanks, Inki Dae
problems with this interface, then it means we have to carry this interface forever, _as well as_ a new cleaned-up one.
Cheers, Daniel
Hi Inki,
On 28 October 2015 at 10:48, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 19:15에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 06:55, Inki Dae inki.dae@samsung.com wrote:
and revive a Exynos specific interface which was used to get fake offset, which is required for application using render node to access a gem memory. For userspace codes for the use of this interface, you can refer to below link, https://github.com/dofmind/libdrm/commit/5cc58d765c61b37a26372de9701f3ffe3a1...
We will post a patch for libdrm after this patch is merged to mainline.
Is there any real (non-libdrm) userspace for this? See Daniel Vetter's reply to the series here: 'In general we wait with merging new userspace ABI until that's really ready, since very often there's some corner cases that you just didn't think about in your toy demo compared to the real thing. Like how to manage buffer caches/reuse for apps that essentially run forever (like X server or a compositor).'
Below link is a libdrm codes used by Tizen platform. https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=6e97...
Thanks for the link, but I meant something like this:
In Tizen platform, there is a buffer manager called TBM(Tizem Buffer Manager), and this manager uses this new interface of libdrm.
Tizen platform can use window systems - wayland or X server - according to version. And the native systems use the TBM interfaces to manage gem buffer.
Is there any open user we can review?
Daniel V's quote above explains the policy: having a userspace patch which simply exposes the same interface and then runs one or two trivial operations is usually not enough to get new interfaces merged. Not only does having an open, reviewable, userspace prove that the interface is suitable and does what it's supposed to be, but it also acts as a benchmark for future changes. Anyone working in future can then review the userspace to make sure they don't break it as an existing user of the interface.
Without the userspace, establishing the semantics of new interfaces is really quite difficult, and you end up with quite a lot of breakage ...
Probably my biggest concern is how well this operates with the proposed PREP/FINI patches. I would really love to see a real userspace which exercises both MAP and PREP/FINI: if that shows
Hmm... Daniel, seems there was your mislead. I will never merge such PREP/FINI interfaces for cache operation until these will be reviewed enough through real user. So this pull request doesn't include them. We are just planning to apply these interfaces to Tizen platform for more test.
Fair enough. It would be great to see a real user for them emerge. My main concern was that there would be an interaction between the map/prep/fini patches which meant that in order for prep/fini to work correctly, effectively a map2 would be required.
Cheers, Daniel
Hi,
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
On 28 October 2015 at 10:48, Inki Dae inki.dae@samsung.com wrote:
In Tizen platform, there is a buffer manager called TBM(Tizem Buffer Manager), and this manager uses this new interface of libdrm.
Tizen platform can use window systems - wayland or X server - according to version. And the native systems use the TBM interfaces to manage gem buffer.
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite difficult/impossible to get access to a generic userspace on the parts you usually test on such as Trats2/5433/7xxx.
Cheers, Daniel
Hi Daniel,
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
Hi,
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
On 28 October 2015 at 10:48, Inki Dae inki.dae@samsung.com wrote:
In Tizen platform, there is a buffer manager called TBM(Tizem Buffer Manager), and this manager uses this new interface of libdrm.
Tizen platform can use window systems - wayland or X server - according to version. And the native systems use the TBM interfaces to manage gem buffer.
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
I think below guide would be very useful to you, https://source.tizen.org/release/tizen-3.0-milestones
And, we have gerrit review system and you could use it also if you sign up at below link, http://review.tizen.org/gerrit/
Thanks, Inki Dae
difficult/impossible to get access to a generic userspace on the parts you usually test on such as Trats2/5433/7xxx.
Cheers, Daniel
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone - and it is unclear how to build them on a generic userspace / if they will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
Thanks very much for your help finding this!
Cheers, Daniel
Hi Daniel,
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Prefix name may be strange but below libtbm backend is used for Trats2 and Odoid-XU3/4. Actually, changing the backend name to 'exynos' instead of 'exynosxxxx' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Thanks, Inki Dae
Thanks very much for your help finding this!
Cheers, Daniel
On 28 October 2015 at 22:37, Inki Dae inki.dae@samsung.com wrote:
Hi Daniel,
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Prefix name may be strange but below libtbm backend is used for Trats2 and Odoid-XU3/4. Actually, changing the backend name to 'exynos' instead of 'exynosxxxx' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Thanks, Inki Dae
Daniel,
Is there still an issue here,
Inki can you send me a pull request without the problematic patch so we can at least merge all the other works you've lined up. We can add this on top once people are happy.
Dave.
Hi Dave,
2015년 11월 03일 08:10에 Dave Airlie 이(가) 쓴 글:
On 28 October 2015 at 22:37, Inki Dae inki.dae@samsung.com wrote:
Hi Daniel,
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Prefix name may be strange but below libtbm backend is used for Trats2 and Odoid-XU3/4. Actually, changing the backend name to 'exynos' instead of 'exynosxxxx' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Thanks, Inki Dae
Daniel,
Is there still an issue here,
Inki can you send me a pull request without the problematic patch so we can at least merge all the other works you've lined up. We can add this on top once people are happy.
Ok, I will request pull again excepting the patch and rebasing on top of drm-next.
The patch, Exynos specific MAP, hasn't been merged yet to libtbm backend even through already tested. So I think it seems reasonable for us to wait for the merged real user, which would be Daniel's answer.
Thanks, Inki Dae
Dave.
On 3 November 2015 at 12:11, Inki Dae inki.dae@samsung.com wrote:
Hi Dave,
2015년 11월 03일 08:10에 Dave Airlie 이(가) 쓴 글:
On 28 October 2015 at 22:37, Inki Dae inki.dae@samsung.com wrote:
Hi Daniel,
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote: > Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Prefix name may be strange but below libtbm backend is used for Trats2 and Odoid-XU3/4. Actually, changing the backend name to 'exynos' instead of 'exynosxxxx' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Thanks, Inki Dae
Daniel,
Is there still an issue here,
Inki can you send me a pull request without the problematic patch so we can at least merge all the other works you've lined up. We can add this on top once people are happy.
Ok, I will request pull again excepting the patch and rebasing on top of drm-next.
It's not necessary to rebase I don't think, whatever base you are on now is fine.
Dave.
Hi Daniel,
2015년 10월 28일 21:37에 Inki Dae 이(가) 쓴 글:
Hi Daniel,
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Hi Inki,
On 28 October 2015 at 11:16, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 20:00에 Daniel Stone 이(가) 쓴 글:
On 28 October 2015 at 10:58, Daniel Stone daniel@fooishbar.org wrote:
Is there any open user we can review?
For clarity, what I meant by these parts was: is there somewhere we can take TBM + Xorg/Wayland for Exynos hardware? Even better if it's able to run on commercially-available parts such as 5422/5800 (Chromebook 2, ODROID-XU3). As you know, it is quite
Yes, you could get TBM + Xorg/Wayland for Exynos hardware - ODROID-XU3 through below link, https://review.tizen.org/git/
And below is Linux 4.0 kernel for ODROID-XU3/XU4. https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=shortlog;...
Thanks very much for the pointer. I managed to find the exynos Xorg driver in use, but unfortunately the only tbm backend I could find is labelled for exynos4412. Is this backend also usable on 5xxx/XU3, or is that backend really only for Trats2, and the 5xxx backend is private?
Prefix name may be strange but below libtbm backend is used for Trats2 and Odoid-XU3/4. Actually, changing the backend name to 'exynos' instead of 'exynosxxxx' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
We have merged the exynos specific map interface to real user like below, https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
So please, feel free to review. I'd be happy for your reivew. :)
Anyway, in Exynos case, we will use Tizen platform as a real user. This means that all interfaces to be added or modified to -next will be verified on Tizen platform.
Thanks, Inki Dae
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Thanks, Inki Dae
Thanks very much for your help finding this!
Cheers, Daniel
Hi Inki,
On 3 November 2015 at 04:36, Inki Dae inki.dae@samsung.com wrote:
2015년 10월 28일 21:37에 Inki Dae 이(가) 쓴 글:
2015년 10월 28일 20:52에 Daniel Stone 이(가) 쓴 글:
Anyway, regardless of that, as far as I can tell, the Xorg driver uses TBM to do buffer mapping, and the TBM backend uses DUMB_MAP rather than the new call here. Is there something I'm missing?
You are right. I found that the patch applied to the backend exists in local branch. I thought the patch exists already in tizen.org because we had already test. Anyway, the patch will be merged soon.
We have merged the exynos specific map interface to real user like below, https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-ex...
So please, feel free to review. I'd be happy for your reivew. :)
Anyway, in Exynos case, we will use Tizen platform as a real user. This means that all interfaces to be added or modified to -next will be verified on Tizen platform.
Thanks a lot for the patch. The note below still stands, but I have now have no objection to merging the patch.
(In any case, having separate-from-Tizen userspace graphics stack repositories would be very welcome, I think: there are a huge number of repositories for Tizen - something like six copies of libtbm alone
- and it is unclear how to build them on a generic userspace / if they
will actually build at all / if they will run on mainline kernels. Having a separate tree will make it very clear to people how to get things working on top of a mainline/staged-for-next kernel.)
One libtbm is common library used by Tizen platform, which has Tizen standard API and the interfaces of the libtbm will never changed. Others are all backend libraries. In fact, Tizen supports various boards based on various SoC such as snapdragon, allwinner, spreadtrum and Exynos. Among them, only Exynos will run on mainline kernels as of now.
Oh, sure - I just meant an easy way to get them to run on an existing userspace, without having to build a completely different distro from scratch; it seems quite involved to get the test system running.
Cheers, Daniel
Hi Dave,
There was one patch I missed. Sorry about this.
Below patch removes the hack codes used to build page array and uses more generic way instead. drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
I have merged this patch to exynos-drm-next just before.
Thanks, Inki Dae
2015년 10월 28일 15:55에 Inki Dae 이(가) 쓴 글:
Hi Dave,
This pull request includes comprehensive cleanups to HDMI part and several fixups, and revive a Exynos specific interface which was used to get fake offset, which is required for application using render node to access a gem memory. For userspace codes for the use of this interface, you can refer to below link, https://github.com/dofmind/libdrm/commit/5cc58d765c61b37a26372de9701f3ffe3a1...
We will post a patch for libdrm after this patch is merged to mainline.
In addition, this pull request includes also a defconfig patch which enables mixer driver as default. For this, I got already Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer.
Please kindly let me know if there is any problem.
Thanks, Inki Dae
The following changes since commit d7e1bc3f5e70c5a106606e33cfa4d413459611ba:
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next (2015-10-23 11:54:03 +1000)
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 01bdaac3d7febed08e1b257a9cbb07e04ba8ce4c:
ARM: exynos_defconfig: enable Exynos DRM Mixer driver (2015-10-28 15:18:31 +0900)
Andrzej Hajda (27): drm/exynos/hdmi: remove support for deprecated compatible drm/exynos/hdmi: use mappings for registers with IP dependent address drm/exynos/hdmi: move PLL stabilization check code to separate function drm/exynos/hdmi: simplify HDMI-PHY power sequence drm/exynos/hdmi: replace all writeb with writel drm/exynos/hdmi: fix removal order drm/exynos/hdmi: use optional regulator_get for hdmi-en drm/exynos/hdmi: use constant size array for regulators drm/exynos/hdmi: simplify clock re-parenting drm/exynos/hdmi: convert to gpiod API drm/exynos/hdmi: remove deprecated hdmi_resources structure drm/exynos/hdmi: convert container_of macro to inline function drm/exynos/hdmi: improve HDMI/ACR related code drm/exynos/hdmi: remove unused field drm/exynos/decon5433: add PCLK clock drm/exynos/decon5433: fix timing registers writes drm/exynos/decon5433: add function to set particular register bits drm/exynos/decon5433: merge different flag fields drm/exynos/decon5433: remove duplicated initialization drm/exynos/decon5433: add support for DECON-TV drm/exynos: add atomic_check callback to exynos_crtc drm/exynos/mixer: replace direct cross-driver call with drm mode validation drm/exynos: separate Mixer and HDMI drivers drm/exynos: abstract out common dependency drm/exynos: re-arrange Kconfig entries drm/exynos: simplify Kconfig component names ARM: exynos_defconfig: enable Exynos DRM Mixer driver
Gustavo Padovan (2): drm/exynos: add global macro for the default primary plane drm/exynos: add cursor plane support
Ingi Kim (1): drm/exynos: fix spelling errors
Joonyoung Shim (3): drm/exynos: fix to detach device of iommu drm/exynos: cleanup name of gem object for exynos_drm drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
Tomasz Stanislawski (1): drm: exynos: mixer: fix using usleep() in atomic context
arch/arm/configs/exynos_defconfig | 1 + drivers/gpu/drm/exynos/Kconfig | 75 ++-- drivers/gpu/drm/exynos/Makefile | 3 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 324 +++++++++-------- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 45 ++- drivers/gpu/drm/exynos/exynos_drm_fb.h | 5 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 53 +-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 248 +++++++------ drivers/gpu/drm/exynos/exynos_drm_gem.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 + drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 496 +++++++++----------------- drivers/gpu/drm/exynos/exynos_mixer.c | 17 +- drivers/gpu/drm/exynos/exynos_mixer.h | 20 -- drivers/gpu/drm/exynos/regs-hdmi.h | 33 +- include/uapi/drm/exynos_drm.h | 17 +- include/video/exynos5433_decon.h | 29 ++ 26 files changed, 703 insertions(+), 780 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Daniel Stone -
Dave Airlie -
Inki Dae