drm/exynos: when to call dma_map_sg() on a GEM object?
Hi Tobias, 2015ë 11ì 02ì¼ 19:29ì Tobias Jakobi ì´(ê°) ì´ ê¸: > Hello Joonyoung, > > > Joonyoung Shim wrote: >> On 10/31/2015 05:44 AM, Tobias Jakobi wrote: >>> Hey there, >>> >>> this question arose during some discussion with someone concerning the >>> Exynos mixer and G2D. >>> >>> The question is the following. Consider the Exynos mixer when run under >>> the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU >>> mapping so that the mixer can scanout the framebuffer? >>> >> >> IOMMU mapping is in dma_alloc_attrs(). Already IOMMU was integrated in >> the DMA mapping API on ARM arch. > Thanks, I'm going to take a closer look at dma_alloc_attrs() then. > > >>> There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's >>> currently exclusively used for the G2D and only when dealing with >>> userptr (and not GEM) there. >>> >>> I was looking at exynos_drm_alloc_buf() since this called when >>> allocating a BO to be used as scanout. >>> >>> I see dma_alloc_attrs() being called, which also sets the DMA address >>> that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is >>> passed, so no mapping is done at this point. >>> >> >> Did you read Documentation/DMA-attributes.txt document? > I did, but I guess I should read it again... > > >> DMA_ATTR_NO_KERNEL_MAPPING is just to avoid creating a kernel virtual >> mapping for the allocated buffer on ARM arch. > Ah OK, so the IOMMU mapping is always established. > > >>> Is the mapping done somewhere else, or is it simply not necessary here? >>> >> >> What is the mapping you mean? As you know, the DMA address of the >> memory gets from dma_alloc_attrs() and it can be used by device. There >> is no reason to use dma_map_*(). >>From my understanding the mixer doesn't directly access the physical > memory when running under IOMMU. It accesses memory through sysmmu_tv, > so my question was who does the setup so that sysmmu_tv "knows" how to > translate memory accesses. That is done by dma-mapping API, dma_alloc_attrs function in case of Exynos DRM. This dma mapping API calls internally iommu_map function of iommu framework after allocating physical pages and iova space, and the iova space will be mapped with physical pages. Please, look into the dma mapping framework - arch/arm/mm/dma-mapping.c - if you want to understand. I think you could understand it easily if you tried to look into exynos_drm_alloc_buf function before asking for it. Thanks, Inki Dae > > > With best wishes, > Tobias > > >> >> Thanks. >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[GIT PULL] exynos-drm-next
Hi Daniel, 2015ë 10ì 28ì¼ 20:52ì Daniel Stone ì´(ê°) ì´ ê¸: > Hi Inki, > > On 28 October 2015 at 11:16, Inki Dae wrote: >> 2015ë 10ì 28ì¼ 20:00ì Daniel Stone ì´(ê°) ì´ ê¸: >>> On 28 October 2015 at 10:58, Daniel Stone 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;h=refs/heads/tizen > > 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 'exynos' would be more reasonable. https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-exynos4412.git;a=summary > > 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 >
[GIT PULL] exynos-drm-next
Hi Daniel, 2015ë 10ì 28ì¼ 20:00ì Daniel Stone ì´(ê°) ì´ ê¸: > Hi, > > On 28 October 2015 at 10:58, Daniel Stone wrote: >> On 28 October 2015 at 10:48, Inki Dae 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;h=refs/heads/tizen 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 >
[GIT PULL] exynos-drm-next
Hi Daniel, 2015ë 10ì 28ì¼ 19:15ì Daniel Stone ì´(ê°) ì´ ê¸: > Hi Inki, > > On 28 October 2015 at 06:55, Inki Dae 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/5cc58d765c61b37a26372de9701f3ffe3a1bef70 >> >>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=6e97f25af63a9511ddd3b195a0b844671b8d1a5d 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 >
[GIT PULL] exynos-drm-next
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/5cc58d765c61b37a26372de9701f3ffe3a1bef70 > >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
[GIT PULL] exynos-drm-next
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/5cc58d765c61b37a26372de9701f3ffe3a1bef70 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
[PATCH 3/7] ARM: exynos_defconfig: enable Exynos DRM Mixer driver
2015ë 10ì 28ì¼ 15:09ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: > On 26.10.2015 21:03, Andrzej Hajda wrote: >> Mixer driver is selected by CONFIG_DRM_EXYNOS_HDMI option. Since Exynos5433 >> HDMI does not require Mixer. There will be separate options to select Mixer >> and HDMI. Adding new option to defconfig before Kconfig will allow to keep >> bisectability. >> >> Signed-off-by: Andrzej Hajda >> --- >> arch/arm/configs/exynos_defconfig | 1 + >> 1 file changed, 1 insertion(+) > > Reviewed-by: Krzysztof Kozlowski > > I guess this will go with rest of patchset through Exynos DRM tree: > Acked-by: Krzysztof Kozlowski Thanks for ack. I will pick it up. Thanks, Inki Dae > > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 0/7] add atomic_check callback to exynos_crtc
2015ë 10ì 28ì¼ 10:37ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: > On 26.10.2015 21:03, Andrzej Hajda wrote: >> Hi Inki, >> >> This patchset removes hacky mode validation in Mixer driver by adding >> atomic_check callback to exynos_crtc and replacing direct function call >> with DRM framework validation. As a result HDMI driver does not depend >> anymore >> on MIXER driver and both drivers can be selected with different Kconfig >> options, >> it is usefull especially for latests SoCs which do have HDMI IP but do not >> have >> MIXER IP. >> Additionally patchset performs small Kconfig refactoring. >> >> Krzysztof could you look at exynos_defconfig patch. Maybe it would be good >> to merge it before next patch to allow full bi-sectability :) > > I would be happy to see similar for multi_v7. HDMI is already there. > > I also wonder why actually DRM_EXYNOS_HDMI has to depend on MIXER or DECON? DECON controller has two kinds of data paths in case of Exynos5433 or later. One is Display path and other is TV path. So it'd be reasonable for DRM_EXYNOS_HDMI to depend on MIXER or DECON - TV path of DECON controller transfers Display data to HDMI like MIXER IP of previous Exynos SoC did. Thanks, Inki Dae > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV
2015-10-23 22:03 GMT+09:00 Andrzej Hajda :
>
> On 10/23/2015 01:55 PM, Inki Dae wrote:
> > Hi Andrzej,
> >
> >
> > 2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> >> DECON-TV IP is responsible for generating video stream which is transferred
> >> to HDMI IP. It is almost fully compatible with DECON IP.
> >>
> >> The patch is based on initial work of Hyungwon Hwang.
> >>
> >> Signed-off-by: Andrzej Hajda
> >> ---
> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 154
> >> --
> >> include/video/exynos5433_decon.h | 29 +
> >> 2 files changed, 122 insertions(+), 61 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> index 3c9aa4e..fbe1b31 100644
> >> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> @@ -13,6 +13,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >>
> >> @@ -37,6 +38,12 @@ static const char * const decon_clks_name[] = {
> >> "sclk_decon_eclk",
> >> };
> >>
> >> +enum decon_iftype {
> >> +IFTYPE_RGB,
> >> +IFTYPE_I80,
> >> +IFTYPE_HDMI
> >> +};
> >> +
> >> enum decon_flag_bits {
> >> BIT_CLKS_ENABLED,
> >> BIT_IRQS_ENABLED,
> >> @@ -53,7 +60,8 @@ struct decon_context {
> >> struct clk *clks[ARRAY_SIZE(decon_clks_name)];
> >> int pipe;
> >> unsigned long flags;
> >> -booli80_if;
> >> +enum decon_iftype out_type;
> >> +int first_win;
> >> };
> >>
> >> static const uint32_t decon_formats[] = {
> >> @@ -80,7 +88,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc
> >> *crtc)
> >>
> >> if (test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
> >> val = VIDINTCON0_INTEN;
> >> -if (ctx->i80_if)
> >> +if (ctx->out_type == IFTYPE_I80)
> >> val |= VIDINTCON0_FRAMEDONE;
> >> else
> >> val |= VIDINTCON0_INTFRMEN;
> >> @@ -104,8 +112,11 @@ static void decon_disable_vblank(struct
> >> exynos_drm_crtc *crtc)
> >>
> >> static void decon_setup_trigger(struct decon_context *ctx)
> >> {
> >> -u32 val = TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> -TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN;
> >> +u32 val = (ctx->out_type != IFTYPE_HDMI)
> >> +? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> + TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> >> +: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> + TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
> >> writel(val, ctx->addr + DECON_TRIGCON);
> >> }
> >>
> >> @@ -118,13 +129,22 @@ static void decon_commit(struct exynos_drm_crtc
> >> *crtc)
> >> if (test_bit(BIT_SUSPENDED, >flags))
> >> return;
> >>
> >> +if (ctx->out_type == IFTYPE_HDMI) {
> >> +m->crtc_hsync_start = m->crtc_hdisplay + 10;
> >> +m->crtc_hsync_end = m->crtc_htotal - 92;
> >> +m->crtc_vsync_start = m->crtc_vdisplay + 1;
> >> +m->crtc_vsync_end = m->crtc_vsync_start + 1;
> >> +}
> >> +
> >> +decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> >> +
> >> /* enable clock gate */
> >> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> >> writel(val, ctx->addr + DECON_CMU);
> >>
> >> /* lcd on and use command if */
> >> val = VIDOUT_LCD_ON;
> >> -if (ctx->i80_if)
> >> +if (ctx->out_type == IFTYPE_I80)
> >> val |= VIDOUT_COMMAND_IF;
> >> else
> >> val |= VIDOUT_RGB_IF;
> >> @@ -134,7 +154,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> >> VIDTCON2_HOZVAL(m->hdisplay - 1);
[PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV
gned int
> win,
>struct drm_framebuffer *fb)
> {
> @@ -238,6 +252,10 @@ static void decon_atomic_begin(struct exynos_drm_crtc
> *crtc,
> decon_shadow_protect_win(ctx, plane->zpos, true);
> }
>
> +#define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
> +#define COORDINATE_X(x) BIT_VAL((x), 23, 12)
> +#define COORDINATE_Y(x) BIT_VAL((x), 11, 0)
> +
> static void decon_update_plane(struct exynos_drm_crtc *crtc,
> struct exynos_drm_plane *plane)
> {
> @@ -271,8 +289,12 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
> val = plane->dma_addr[0] + pitch * plane->crtc_h;
> writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
>
> - val = OFFSIZE(pitch - plane->crtc_w * bpp)
> - | PAGEWIDTH(plane->crtc_w * bpp);
> + if (ctx->out_type != IFTYPE_HDMI)
> + val = BIT_VAL(pitch - plane->crtc_w * bpp, 27, 14)
> + | BIT_VAL(plane->crtc_w * bpp, 13, 0);
> + else
> + val = BIT_VAL(pitch - plane->crtc_w * bpp, 29, 15)
> + | BIT_VAL(plane->crtc_w * bpp, 14, 0);
> writel(val, ctx->addr + DECON_VIDW0xADD2(win));
>
> decon_win_set_pixfmt(ctx, win, state->fb);
> @@ -314,7 +336,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc,
>
> decon_shadow_protect_win(ctx, plane->zpos, false);
>
> - if (ctx->i80_if)
> + if (ctx->out_type == IFTYPE_I80)
> set_bit(BIT_WIN_UPDATED, >flags);
> }
>
> @@ -339,6 +361,17 @@ static void decon_swreset(struct decon_context *ctx)
> }
>
> WARN(tries == 0, "failed to software reset DECON\n");
> +
> + if (ctx->out_type != IFTYPE_HDMI)
> + return;
> +
> + writel(VIDCON0_CLKVALUP | VIDCON0_VLCKFREE, ctx->addr + DECON_VIDCON0);
> + decon_set_bits(ctx, DECON_CMU,
> +CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F, ~0);
> + writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
> + writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
> +ctx->addr + DECON_CRCCTRL);
> + decon_setup_trigger(ctx);
> }
>
> static void decon_enable(struct exynos_drm_crtc *crtc)
> @@ -387,7 +420,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
>* suspend that connector. Otherwise we might try to scan from
>* a destroyed buffer later.
>*/
> - for (i = 0; i < WINDOWS_NR; i++)
> + for (i = ctx->first_win; i < WINDOWS_NR; i++)
> decon_disable_plane(crtc, >planes[i]);
>
> decon_swreset(ctx);
> @@ -461,25 +494,30 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> struct drm_device *drm_dev = data;
> struct exynos_drm_private *priv = drm_dev->dev_private;
> struct exynos_drm_plane *exynos_plane;
> + enum exynos_drm_output_type out_type;
> enum drm_plane_type type;
> - unsigned int zpos;
> + unsigned int win;
> int ret;
>
> ctx->drm_dev = drm_dev;
> ctx->pipe = priv->pipe++;
>
> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = exynos_plane_get_type(zpos, CURSOR_WIN);
> - ret = exynos_plane_init(drm_dev, >planes[zpos],
> + for (win = ctx->first_win; win < WINDOWS_NR; win++) {
> + int tmp = (win == ctx->first_win) ? 0 : win;
AFAIK, DECON TV for Exynos5433 SoC has four hardware overlays so I guess
you used ctx->first_win to initialize four planes in case of IFTYPE_HDMI.
However, with IFTYPE_HDMI ctx->first_win has 1, as a result,
ctx->planes[] will have 0, 2nd, 3rd and 4th planes and this means we
should use 0, 2nd ~ 4th hardware overlay excepting 1st overlay. Is this
your intention?
Shouldn't ctx->planes[] have 1st, 2nd ,3rd and 4th planes so that we can
use 1st ~ 4th hardware overlay for DECON TV?
DECON TV for Exynos5433 SoC can use only 1st ~ 4th hardware overlays.
And other thing, it may be trivial but I think it'd be better to use
'ovl' instead of 'tmp.
Thanks,
Inki Dae
[PATCH 6/9] drm/exynos: switch to new buffer allocation
Hi,
How about combining patch 5 and 6?
Patch 5 just introduces new internal API but these API aren't used
anywhere in patch 5.
Thanks,
Inki Dae
2015ë
10ì 13ì¼ 16:00ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The buffer allocation using DMA mapping API can't support non-continuous
> buffer on non-iommu and cachable buffer, so switch to new buffer
> allocation using drm_gem_get/put_pages() and doesn't use DMA mapping API
> for mmap except allocation of physically continuous buffer on non-iommu.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 90
> +++--
> 1 file changed, 29 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index d982d46b04da..163d113df1ab 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -77,10 +77,7 @@ static int exynos_drm_alloc_dma(struct exynos_drm_gem
> *exynos_gem)
>
> init_dma_attrs(_gem->dma_attrs);
>
> - if (exynos_gem->flags & EXYNOS_BO_WC ||
> - !(exynos_gem->flags & EXYNOS_BO_CACHABLE))
> - dma_set_attr(DMA_ATTR_WRITE_COMBINE, _gem->dma_attrs);
> -
> + dma_set_attr(DMA_ATTR_WRITE_COMBINE, _gem->dma_attrs);
> dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
>
> nr_pages = exynos_gem->size >> PAGE_SHIFT;
> @@ -128,51 +125,21 @@ static void exynos_drm_free_dma(struct exynos_drm_gem
> *exynos_gem)
> static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem)
> {
> struct drm_device *dev = exynos_gem->base.dev;
> - enum dma_attr attr;
> - unsigned int nr_pages;
> + int ret;
>
> if (exynos_gem->dma_addr) {
> DRM_DEBUG_KMS("already allocated.\n");
> return 0;
> }
>
> - if (!is_drm_iommu_supported(dev))
> - return exynos_drm_alloc_dma(exynos_gem);
> -
> - init_dma_attrs(_gem->dma_attrs);
> -
> - /*
> - * if EXYNOS_BO_CONTIG, fully physically contiguous memory
> - * region will be allocated else physically contiguous
> - * as possible.
> - */
> - if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
> - dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, _gem->dma_attrs);
> -
> - /* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping */
> - if (exynos_gem->flags & EXYNOS_BO_WC ||
> - !(exynos_gem->flags & EXYNOS_BO_CACHABLE))
> - attr = DMA_ATTR_WRITE_COMBINE;
> -
> - dma_set_attr(attr, _gem->dma_attrs);
> - dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);
> -
> - nr_pages = exynos_gem->size >> PAGE_SHIFT;
> -
> - exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
> - _gem->dma_addr, GFP_KERNEL,
> - _gem->dma_attrs);
> - if (!exynos_gem->cookie) {
> - DRM_ERROR("failed to allocate buffer.\n");
> - if (exynos_gem->pages)
> - drm_free_large(exynos_gem->pages);
> - return -ENOMEM;
> + if (!is_drm_iommu_supported(dev)) {
> + if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
> + return exynos_drm_alloc_dma(exynos_gem);
> }
>
> - exynos_gem->pages = exynos_gem->cookie;
> -
> - DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
> - (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
> + ret = exynos_drm_get_pages(exynos_gem);
> + if (ret < 0)
> + return ret;
>
> return 0;
> }
> @@ -186,15 +153,12 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
> *exynos_gem)
> return;
> }
>
> - if (!is_drm_iommu_supported(dev))
> - return exynos_drm_free_dma(exynos_gem);
> -
> - DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
> - (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
> + if (!is_drm_iommu_supported(dev)) {
> + if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
> + return exynos_drm_free_dma(exynos_gem);
> + }
>
> - dma_free_attrs(dev->dev, exynos_gem->size, exynos_gem->cookie,
> - (dma_addr_t)exynos_gem->dma_addr,
> - _gem->dma_attrs);
> + exynos_drm_put_pages(exynos_gem);
> }
>
> static int exyno
[PATCH 00/10] drm/exynos: add pm_runtime support
Hi Gustavo, Please ping~ and re-base on top of exynos-drm-next. Thanks, Inki Dae 2015ë 09ì 05ì¼ 05:15ì Gustavo Padovan ì´(ê°) ì´ ê¸: > From: Gustavo Padovan > > Hi, > > This series adds proper runtime PM suport to CRTCs and Encoders, so > now instead of relying on 'suspended' or 'enabled' flags to track when > the CRTC or Encoder is enabled we let the pm_runtime subsystem do it for us > and remove all the flags. This is a important step to the atomic > suspend/resume > support that will land in drm anytime soon. > > Please review! > > Gustavo > > Gustavo Padovan (10): >drm/exynos: do not start enabling DP at bind() phase >drm/exynos: add pm_runtime to DP >drm/exynos: add pm_runtime to HDMI >drm/exynos: add pm_runtime to Mixer >drm/exynos: remove exynos_crtc commit() callback >drm/exynos: Remove exynos_crtc commit() callback >drm/exynos: add pm_runtime to FIMD >drm/exynos: Enable DP clock directly from FIMD >drm/exynos: add pm_runtime to DECON 5433 >drm/exynos: add pm_runtime to DECON 7 > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 90 -- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 126 > +++-- > drivers/gpu/drm/exynos/exynos_dp_core.c | 57 ++-- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 -- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 -- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 129 > -- > drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +++ > drivers/gpu/drm/exynos/exynos_mixer.c | 125 > - > 8 files changed, 275 insertions(+), 325 deletions(-) >
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
2015ë
10ì 13ì¼ 14:23ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> On 10/13/2015 02:11 PM, Inki Dae wrote:
>>
>> Merged.
>>
>
> Thanks for merge but this will be conflicted with the patch of Daniel,
> http://patchwork.freedesktop.org/patch/60565/
Right. With Daniel patch, DRM_UNLOCKED flag isn't needed anymore for
driver specific ioctls.
>
> I found it on next-20151012, do you want v2 patch that DRM_UNLOCKED flag
> is dropped?
It'd be better to drop the flag for cleanup. Anyway, I can do it.
Thanks,
Inki Dae
>
> Thanks.
>
>> Thanks,
>> Inki Dae
>>
>> 2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
>>> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
>>> ioctl") removed it same with the ioctl that this patch adds. The reason
>>> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
>>> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>>>
>>> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
>>> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
>>>drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>>>drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
>>>include/uapi/drm/exynos_drm.h | 17 -
>>>4 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index f0a5839..8fd7201 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
>>> exynos_drm_gem_vm_ops = {
>>>static const struct drm_ioctl_desc exynos_ioctls[] = {
>>>DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>>>DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>> +DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
>>> +DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>>DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
>>>DRM_UNLOCKED | DRM_RENDER_ALLOW),
>>>DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index f1dcdd0..29f4875 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device
>>> *dev, void *data,
>>>return 0;
>>>}
>>>
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv)
>>> +{
>>> +struct drm_exynos_gem_map *args = data;
>>> +
>>> +return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
>>> + >offset);
>>> +}
>>> +
>>>dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
>>>unsigned int gem_handle,
>>>struct drm_file *filp)
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 37ab8b2..0d0ab27 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
>>> drm_device *dev,
>>>int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
>>>struct drm_file *file_priv);
>>>
>>> +/* get fake-offset of gem object that can be used with mmap. */
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv);
>>> +
>>>/*
>>> * get dma address from gem handle and this function could be used for
>>> * other drivers such as 2d/3d acceleration drivers.
>>> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
>>> index 5575ed1..18f0601 100644
>>> --- a/include/uapi/drm/exynos_drm.h
>>> +++ b/include/uapi/drm/exynos_drm.h
>>> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
>>>};
>>>
>>>/**
>>> +
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
Merged.
Thanks,
Inki Dae
2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
> ioctl") removed it same with the ioctl that this patch adds. The reason
> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>
> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
> include/uapi/drm/exynos_drm.h | 17 -
> 4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index f0a5839..8fd7201 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
> exynos_drm_gem_vm_ops = {
> static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
> + DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
> DRM_UNLOCKED | DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index f1dcdd0..29f4875 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_exynos_gem_map *args = data;
> +
> + return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
> + >offset);
> +}
> +
> dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
> unsigned int gem_handle,
> struct drm_file *filp)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 37ab8b2..0d0ab27 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
> drm_device *dev,
> int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
>
> +/* get fake-offset of gem object that can be used with mmap. */
> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> +
> /*
>* get dma address from gem handle and this function could be used for
>* other drivers such as 2d/3d acceleration drivers.
> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
> index 5575ed1..18f0601 100644
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
> };
>
> /**
> + * A structure for getting a fake-offset that can be used with mmap.
> + *
> + * @handle: handle of gem object.
> + * @reserved: just padding to be 64-bit aligned.
> + * @offset: a fake-offset of gem object.
> + */
> +struct drm_exynos_gem_map {
> + __u32 handle;
> + __u32 reserved;
> + __u64 offset;
> +};
> +
> +/**
>* A structure to gem information.
>*
>* @handle: a handle to gem object created.
> @@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
> };
>
> #define DRM_EXYNOS_GEM_CREATE 0x00
> +#define DRM_EXYNOS_GEM_MAP 0x01
> /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
> #define DRM_EXYNOS_GEM_GET 0x04
> #define DRM_EXYNOS_VIDI_CONNECTION 0x07
> @@ -301,7 +315,8 @@ struct drm_exynos_ipp_cmd_ctrl {
>
> #define DRM_IOCTL_EXYNOS_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
> DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
> -
> +#define DRM_IOCTL_EXYNOS_GEM_MAP DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_EXYNOS_GEM_MAP, struct drm_exynos_gem_map)
> #define DRM_IOCTL_EXYNOS_GEM_GETDRM_IOWR(DRM_COMMAND_BASE + \
> DRM_EXYNOS_GEM_GET, struct drm_exynos_gem_info)
>
>
[PATCH] drm/exynos: cleanup name of gem object for exynos_drm
Merged.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 09:33ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> Struct of gem object in exynos_drm driver is struct exynos_drm_gem_obj.
> It's too long and we can know its meaning of name without _obj postfix.
>
> We use several names to variable name of gem object for exynos_drm -
> exynos_gem_obj, gem_obj and obj. Especially "obj" name can cause
> misunderstanding with variable name "obj" of struct drm_gem_object.
>
> This will clean about name of gem object for exynos_drm as follows.
> s/struct exynos_drm_gem_obj/struct exynos_drm_gem
> s/exynos_gem_obj or gem_obj or obj/exynos_gem
>
> Signed-off-by: Joonyoung Shim
> ---
> 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_gem.c | 239
> +++---
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 15 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 9 +-
> 6 files changed, 184 insertions(+), 182 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 0842808..fcea28b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -32,15 +32,15 @@
>* exynos specific framebuffer structure.
>*
>* @fb: drm framebuffer obejct.
> - * @exynos_gem_obj: array of exynos specific gem object containing a gem
> object.
> + * @exynos_gem: array of exynos specific gem object containing a gem object.
>*/
> struct exynos_drm_fb {
> - struct drm_framebuffer fb;
> - struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
> + struct drm_framebuffer fb;
> + struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
> };
>
> static int check_fb_gem_memory_type(struct drm_device *drm_dev,
> - struct exynos_drm_gem_obj *exynos_gem_obj)
> + struct exynos_drm_gem *exynos_gem)
> {
> unsigned int flags;
>
> @@ -51,7 +51,7 @@ static int check_fb_gem_memory_type(struct drm_device
> *drm_dev,
> if (is_drm_iommu_supported(drm_dev))
> return 0;
>
> - flags = exynos_gem_obj->flags;
> + flags = exynos_gem->flags;
>
> /*
>* without iommu support, not support physically non-continuous memory
> @@ -75,13 +75,13 @@ static void exynos_drm_fb_destroy(struct drm_framebuffer
> *fb)
>
> drm_framebuffer_cleanup(fb);
>
> - for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem_obj); i++) {
> + for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem); i++) {
> struct drm_gem_object *obj;
>
> - if (exynos_fb->exynos_gem_obj[i] == NULL)
> + if (exynos_fb->exynos_gem[i] == NULL)
> continue;
>
> - obj = _fb->exynos_gem_obj[i]->base;
> + obj = _fb->exynos_gem[i]->base;
> drm_gem_object_unreference_unlocked(obj);
> }
>
> @@ -96,7 +96,7 @@ static int exynos_drm_fb_create_handle(struct
> drm_framebuffer *fb,
> struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
>
> return drm_gem_handle_create(file_priv,
> - _fb->exynos_gem_obj[0]->base, handle);
> + _fb->exynos_gem[0]->base, handle);
> }
>
> static int exynos_drm_fb_dirty(struct drm_framebuffer *fb,
> @@ -118,7 +118,7 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs =
> {
> struct drm_framebuffer *
> exynos_drm_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> - struct exynos_drm_gem_obj **gem_obj,
> + struct exynos_drm_gem **exynos_gem,
> int count)
> {
> struct exynos_drm_fb *exynos_fb;
> @@ -130,11 +130,11 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
> return ERR_PTR(-ENOMEM);
>
> for (i = 0; i < count; i++) {
> - ret = check_fb_gem_memory_type(dev, gem_obj[i]);
> + ret = check_fb_gem_memory_type(dev, exynos_gem[i]);
> if (ret < 0)
> goto err;
>
> - exynos_fb->exynos_gem_obj[i] = gem_obj[i];
> + exynos_fb->exynos_gem[i] = exynos_gem[i];
> }
>
> drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
> @@ -156,7 +156,7 @@ static struct drm_framebuffer *
> exynos_user_fb_create(struct drm_device *dev, struct drm
[PATCH] drm/exynos: fix to detach device of iommu
Merged. Thanks, Inki Dae 2015ë 10ì 02ì¼ 09:30ì Joonyoung Shim ì´(ê°) ì´ ê¸: > The arm_iommu_detach_device() is a function to detach device of iommu > attached by arm_iommu_attach_device(). The exynos-drm uses > arm_iommu_attach_device() so it should use arm_iommu_detach_device() to > detach device of iommu, not iommu_detach_device(). > > The drm_release_iommu_mapping() is a function to release mapping of > iommu created by arm_iommu_create_mapping(). It is called by > exynos_drm_unload() so shouldn't be called by drm_iommu_detach_device(). > > Signed-off-by: Joonyoung Shim > Cc: # v3.8+ > --- > drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > index 055e8ec..d73b9ad 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > @@ -139,6 +139,5 @@ void drm_iommu_detach_device(struct drm_device *drm_dev, > if (!mapping || !mapping->domain) > return; > > - iommu_detach_device(mapping->domain, subdrv_dev); > - drm_release_iommu_mapping(drm_dev); > + arm_iommu_detach_device(subdrv_dev); > } >
[PATCH] drm/exynos: fix spelling errors
Hi, Ingi.
Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 17:59ì Ingi Kim ì´(ê°) ì´ ê¸:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
>
> Signed-off-by: Ingi Kim
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 ++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context
> *ctx, u32 fmt)
> EXYNOS_MSCTRL_C_INT_IN_2PLANE);
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
> cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
> cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
> return -EINVAL;
> }
>
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
> property->prop_id, buf_id, buf_type);
>
> if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
> return -ENOMEM;
> }
>
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context
> *ctx, u32 fmt)
> cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
> cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
> fmt);
> return -EINVAL;
> }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
> cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
> return -EINVAL;
> }
>
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
> property->prop_id, buf_id, buf_type);
>
> if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
> return -ENOMEM;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
> GSC_IN_YUV420_2P);
> break;
> default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
> return -EINVAL;
> }
>
> @@ -595,7 +595,7 @@ static
[PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches
Hi Andrzej, For all patches, merged excepting patch 2 which cleans up dt binding document. Thanks, Inki Dae 2015ë 09ì 25ì¼ 21:48ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi, > > This is another set of cleanup/improvement patches for HDMI. > > The patchset is based on exynos-drm-next. > It was tested on Universal and Odroid U3. > > Regards > Andrzej > > > Andrzej Hajda (15): >drm/exynos/hdmi: remove support for deprecated compatible >dt-bindings: remove deprecated compatible string from exynos-hdmi >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 > > Tomasz Stanislawski (1): >drm: exynos: mixer: fix using usleep() in atomic context > > .../devicetree/bindings/video/exynos_hdmi.txt | 7 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 491 > +++-- > drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- > drivers/gpu/drm/exynos/regs-hdmi.h | 33 +- > 4 files changed, 189 insertions(+), 344 deletions(-) >
[PATCH 07/10] drm/exynos: add pm_runtime to FIMD
Also ping~~
2015ë
09ì 19ì¼ 12:53ì Inki Dae ì´(ê°) ì´ ê¸:
> On 2015ë
09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Let pm_runtime handle the enabling/disabling of the device with proper
>> refcnt instead of rely on specific flags to track the enabled state.
>>
>> Signed-off-by: Gustavo Padovan
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 -
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91
>> +++
>> 3 files changed, 37 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 79b2b22..838a9c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
>> .commit = decon_commit,
>> .enable_vblank = decon_enable_vblank,
>> .disable_vblank = decon_disable_vblank,
>> -.commit = decon_commit,
>
> Above wouldn't be related to this patch.
>
>> .atomic_begin = decon_atomic_begin,
>> .update_plane = decon_update_plane,
>> .disable_plane = decon_disable_plane,
>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> index f3826dc..e4646e2 100644
>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> @@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops =
>> {
>> .enable = decon_enable,
>> .disable = decon_disable,
>> .mode_fixup = decon_mode_fixup,
>> -.commit = decon_commit,
>
> Ditto.
>
> Thanks,
> Inki Dae
>
>> .enable_vblank = decon_enable_vblank,
>> .disable_vblank = decon_disable_vblank,
>> .wait_for_vblank = decon_wait_for_vblank,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 0bbe537..0f17ae0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -160,7 +160,6 @@ struct fimd_context {
>> u32 vidout_con;
>> u32 i80ifcon;
>> booli80_if;
>> -boolsuspended;
>> int pipe;
>> wait_queue_head_t wait_vsync_queue;
>> atomic_twait_vsync_event;
>> @@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc
>> *crtc)
>> struct fimd_context *ctx = crtc->ctx;
>> u32 val;
>>
>> -if (ctx->suspended)
>> -return -EPERM;
>> -
>> if (!test_and_set_bit(0, >irq_flags)) {
>> val = readl(ctx->regs + VIDINTCON0);
>>
>> @@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc
>> *crtc)
>> struct fimd_context *ctx = crtc->ctx;
>> u32 val;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>> if (test_and_clear_bit(0, >irq_flags)) {
>> val = readl(ctx->regs + VIDINTCON0);
>>
>> @@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc
>> *crtc)
>> {
>> struct fimd_context *ctx = crtc->ctx;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>> atomic_set(>wait_vsync_event, 1);
>>
>> /*
>> @@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc
>> *crtc)
>> int pipe = ctx->pipe;
>>
>> /* ensure that vblank interrupt won't be reported to core */
>> -ctx->suspended = false;
>> ctx->pipe = -1;
>>
>> fimd_enable_vblank(ctx->crtc);
>> fimd_wait_for_vblank(ctx->crtc);
>> fimd_disable_vblank(ctx->crtc);
>>
>> -ctx->suspended = true;
>> ctx->pipe = pipe;
>> }
>>
>> @@ -394,9 +382,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>> void *timing_base = ctx->regs + driver_data->timing_base;
>> u32 val, clkdiv;
>>
>> -if (ctx->suspen
[PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD
Gustavo, please ping~~~
2015ë
09ì 19ì¼ 12:51ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Gustavo,
>
> On 2015ë
09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Instead of having a .clock_enable callback enable the dp clock directly
>> from FIMD.
>>
>> Signed-off-by: Gustavo Padovan
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 13 ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 5
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39
>> +---
>> 3 files changed, 21 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 6794982..aa11d18 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -37,11 +37,6 @@
>> #define ctx_from_connector(c) container_of(c, struct
>> exynos_dp_device, \
>> connector)
>>
>> -static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device
>> *dp)
>> -{
>> -return to_exynos_crtc(dp->encoder.crtc);
>> -}
>> -
>> static inline struct exynos_dp_device *encoder_to_dp(
>> struct drm_encoder *e)
>> {
>> @@ -1068,7 +1063,6 @@ static void exynos_dp_mode_set(struct drm_encoder
>> *encoder,
>> static void exynos_dp_enable(struct drm_encoder *encoder)
>> {
>> struct exynos_dp_device *dp = encoder_to_dp(encoder);
>> -struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>>
>> pm_runtime_get_sync(dp->dev);
>>
>> @@ -1079,9 +1073,6 @@ static void exynos_dp_enable(struct drm_encoder
>> *encoder)
>> }
>> }
>>
>> -if (crtc->ops->clock_enable)
>> -crtc->ops->clock_enable(dp_to_crtc(dp), true);
>> -
>> phy_power_on(dp->phy);
>> exynos_dp_init_dp(dp);
>> enable_irq(dp->irq);
>> @@ -1091,7 +1082,6 @@ static void exynos_dp_enable(struct drm_encoder
>> *encoder)
>> static void exynos_dp_disable(struct drm_encoder *encoder)
>> {
>> struct exynos_dp_device *dp = encoder_to_dp(encoder);
>> -struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>>
>> if (dp->panel) {
>> if (drm_panel_disable(dp->panel)) {
>> @@ -1104,9 +1094,6 @@ static void exynos_dp_disable(struct drm_encoder
>> *encoder)
>> flush_work(>hotplug_work);
>> phy_power_off(dp->phy);
>>
>> -if (crtc->ops->clock_enable)
>> -crtc->ops->clock_enable(dp_to_crtc(dp), false);
>> -
>> if (dp->panel) {
>> if (drm_panel_unprepare(dp->panel))
>> DRM_ERROR("failed to turnoff the panel\n");
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 5f1a4d6..ee60619 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -96,10 +96,6 @@ struct exynos_drm_plane {
>>* @disable_plane: disable hardware specific overlay.
>>* @te_handler: trigger to transfer video image at the tearing effect
>>* synchronization signal if there is a page flip request.
>> - * @clock_enable: optional function enabling/disabling display domain clock,
>> - * called from exynos-dp driver before powering up (with
>> - * 'enable' argument as true) and after powering down (with
>> - * 'enable' as false).
>>*/
>> struct exynos_drm_crtc;
>> struct exynos_drm_crtc_ops {
>> @@ -120,7 +116,6 @@ struct exynos_drm_crtc_ops {
>> void (*atomic_flush)(struct exynos_drm_crtc *crtc,
>>struct exynos_drm_plane *plane);
>> void (*te_handler)(struct exynos_drm_crtc *crtc);
>> -void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
>> };
>>
>> /*
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 0f17ae0..3cf2b80 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -573,6 +573,23 @@ static void fimd_win_set_colkey(struct fimd_context
>> *ctx, unsigned int win)
>> writel(keycon1, ctx->regs + WKEYCON1_BASE(win));
>> }
>>
>> +static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bo
[PATCH 2/2] drm/exynos: add cursor plane support
Merged.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
>
> Signed-off-by: Gustavo Padovan
>
> ---
> v2: use the top window for cursor on each crtc
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
> 7 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2f393b1..4b8dd7c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -24,6 +24,7 @@
> #include "exynos_drm_iommu.h"
>
> #define WINDOWS_NR 3
> +#define CURSOR_WIN 2
> #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>
> struct decon_context {
> @@ -450,8 +451,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, >planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7a6c069..aa0ae79 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -41,6 +41,7 @@
> #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>
> #define WINDOWS_NR 2
> +#define CURSOR_WIN 1
>
> struct decon_context {
> struct device *dev;
> @@ -630,8 +631,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> }
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, >planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7776768..caa5255 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -88,6 +88,7 @@
>
> /* FIMD has totally five hardware windows. */
> #define WINDOWS_NR 5
> +#define CURSOR_WIN 4
>
> struct fimd_driver_data {
> unsigned int timing_base;
> @@ -909,8 +910,7 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
> ret = exynos_plane_init(drm_dev, >planes[zpos],
> 1 << ctx->pipe, type, fimd_formats,
> ARRAY_SIZE(fimd_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 7148224..80b2151 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -208,6 +208,17 @@ static void exynos_plane_attach_zpos_property(struct
> drm_plane *plane,
> drm_object_attach_property(>base, prop, zpos);
> }
>
> +enum drm_plane_type exynos_plane_get_type(unsigned int zpos,
> + unsigned int cursor_win)
> +{
> + if (zpos == DEFAULT_WIN)
> + return DRM_PLANE_TYPE_PRIMARY;
> + els
[PATCH 1/2] drm/exynos: add global macro for the default primary plane
Hi Gustavo,
Merged.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
> Some CRTCs were defining a variable to store the default window, but that
> is not necessary as the default (primary) window is always the window zero.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++
> drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
> 6 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 988df06..2f393b1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
> struct exynos_drm_plane planes[WINDOWS_NR];
> void __iomem*addr;
> struct clk *clks[6];
> - unsigned intdefault_win;
> unsigned long irq_flags;
> int pipe;
>
> @@ -451,7 +450,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->pipe = priv->pipe++;
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> ret = exynos_plane_init(drm_dev, >planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> @@ -460,7 +459,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
> ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> _crtc_ops, ctx);
> @@ -557,7 +556,6 @@ static int exynos5433_decon_probe(struct platform_device
> *pdev)
> if (!ctx)
> return -ENOMEM;
>
> - ctx->default_win = 0;
> ctx->dev = dev;
> if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> ctx->i80_if = true;
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0776f38..7a6c069 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
> struct clk *eclk;
> struct clk *vclk;
> void __iomem*regs;
> - unsigned intdefault_win;
> unsigned long irq_flags;
> booli80_if;
> int pipe;
> @@ -631,7 +630,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> }
>
> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> ret = exynos_plane_init(drm_dev, >planes[zpos],
> 1 << ctx->pipe, type, decon_formats,
> @@ -640,7 +639,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
> ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> _crtc_ops, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 5cb9bc3..058abd1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -22,6 +22,8 @@
> #define MAX_PLAN
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request includes regression fixups, build warnings, and trivial cleanups which mostly remove some codes not used anymore. Please, kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit fd03420b5624617a708fb9b13634b41b37c22cfa: Merge tag 'drm-intel-fixes-2015-09-24' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-09-25 06:52:37 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to cda374253f862bd0f43edda6935a48294fe8ed3e: drm/exynos: Staticize local function in exynos_drm_gem.c (2015-10-01 14:29:51 +0900) Daniel Kurtz (1): drm/exynos: Remove useless EXPORT_SYMBOL_GPLs Gustavo Padovan (4): drm/exynos: remove fimd_mode_fixup() drm/exynos: remove decon_mode_fixup() drm/exynos: remove unused mode_fixup() code drm/exynos: fimd: actually disable dp clock Inki Dae (1): drm/exynos: dp: remove suspend/resume functions Joonyoung Shim (8): drm/exynos: fix layering violation of address drm/exynos: fix missed calling of drm_prime_gem_destroy() drm/exynos: remove unnecessary NULL assignment drm/exynos: staticize exynos_drm_gem_init() drm/exynos: cleanup function calling written twice drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl drm/exynos: remove call to drm_gem_free_mmap_offset() drm/exynos: create a fake mmap offset with gem creation Krzysztof Kozlowski (1): drm/exynos: Staticize local function in exynos_drm_gem.c Thierry Reding (3): drm/exynos: Suspend/resume is unused if !PM drm/exynos: fimc: Clock control is unused if !PM drm/exynos: rotator: Clock control is unused if !PM drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 drivers/gpu/drm/exynos/exynos_dp_core.c | 23 --- drivers/gpu/drm/exynos/exynos_drm_core.c| 6 -- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 15 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 -- drivers/gpu/drm/exynos/exynos_drm_fimc.c| 36 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 14 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 94 + drivers/gpu/drm/exynos/exynos_drm_gem.h | 6 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 2 +- 12 files changed, 65 insertions(+), 152 deletions(-)
[PATCH] drm/exynos: dp: remove suspend/resume functions
Hi Emil, On 2015ë 09ì 30ì¼ 21:19, Emil Velikov wrote: > Hi Inki, > > On 30 September 2015 at 12:21, Inki Dae wrote: >> This patch removes unnecessary pm suspend/resume functions. >> >> All kms sub drivers will be controlled by top of Exynos drm driver >> and connector dpms so these sub drivers shouldn't have their own >> pm interfaces. >> > Not sure if you've noticed but this patch seems to do the opposite of > what Gustavo was aiming with an earlier series [1]. I removed just the interfaces related to sleep pm not runtime pm. From long ago, Linux DRM drivers - especially ARM DRM drivers - have been stepping forward to a integrated DRM driver so it'd be reasonable for sleep pm operations of all KMS drivers are controlled by top of DRM driver. It means that Exynos drm driver has already sleep pm interfaces. However, I think a power domain of each kms device couldn't be controlled by the top in case of ARM SoC because kms devices can use a different power domain each other according to Vendor SoC so runtime pm should be controlled by each kms driver, which will be triggered by DRM top. And Gustavo's patch set you mentioned - now being reviewed - will add only runtime pm interfaces to each kms driver. Thanks, Inki Dae > > Cheers, > Emil > > [1] http://lists.freedesktop.org/archives/dri-devel/2015-September/089800.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] drm/exynos: Avoid NULL pointer dereference in resume if bind failed
Hi,
On 2015ë
09ì 28ì¼ 01:11, Charles Keepax wrote:
> If binding failed calling exynos_dp_enable in exynos_dp_resume will
> result in several NULL pointer dereferences. It is much better to
> simply skip suspend/resume handling if bind has failed, do so by
> checking if a drm_dev exists.
Thanks for your patch. However, the pm interfaces of KMS drivers aren't
required because these are controlled by top of Exynos drm driver and
connector dpms. So I posted a patch that it removes pm interfaces of dp
driver.
Thanks,
Inki Dae
>
> Signed-off-by: Charles Keepax
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d66ade0..48baf07 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1388,6 +1388,9 @@ static int exynos_dp_suspend(struct device *dev)
> {
> struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
> + if (!dp->drm_dev)
> + return 0;
> +
> exynos_dp_disable(>encoder);
> return 0;
> }
> @@ -1396,6 +1399,9 @@ static int exynos_dp_resume(struct device *dev)
> {
> struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
> + if (!dp->drm_dev)
> + return 0;
> +
> exynos_dp_enable(>encoder);
> return 0;
> }
>
[PATCH] drm/exynos: dp: remove suspend/resume functions
This patch removes unnecessary pm suspend/resume functions.
All kms sub drivers will be controlled by top of Exynos drm driver
and connector dpms so these sub drivers shouldn't have their own
pm interfaces.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..124fb9a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1383,28 +1383,6 @@ static int exynos_dp_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int exynos_dp_suspend(struct device *dev)
-{
- struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
- exynos_dp_disable(>encoder);
- return 0;
-}
-
-static int exynos_dp_resume(struct device *dev)
-{
- struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
- exynos_dp_enable(>encoder);
- return 0;
-}
-#endif
-
-static const struct dev_pm_ops exynos_dp_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
-};
-
static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1417,7 +1395,6 @@ struct platform_driver dp_driver = {
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
- .pm = _dp_pm_ops,
.of_match_table = exynos_dp_match,
},
};
--
1.9.1
[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()
On 2015ë 09ì 24ì¼ 10:01, Joonyoung Shim wrote: > Hi Inki, > > On 08/17/2015 06:03 PM, Inki Dae wrote: >> On 2015ë 08ì 17ì¼ 17:17, Joonyoung Shim wrote: >>> On 08/17/2015 04:52 PM, Inki Dae wrote: >>>> On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote: >>>>> On 08/16/2015 02:07 PM, Inki Dae wrote: >>>>>> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote: >>>>>>> The drm_gem_object_release() function already performs this cleanup, >>>>>>> so there is no reason to do it explicitly. >>>>>>> >>>>>>> Signed-off-by: Joonyoung Shim >>>>>>> --- >>>>>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- >>>>>>> 1 file changed, 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>>>> index c76aa8a..ab7d029 100644 >>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>>>> @@ -100,8 +100,6 @@ out: >>>>>>> exynos_drm_fini_buf(obj->dev, buf); >>>>>>> exynos_gem_obj->buffer = NULL; >>>>>>> >>>>>>> - drm_gem_free_mmap_offset(obj); >>>>>>> - >>>>>>> /* release file pointer to gem object. */ >>>>>>> drm_gem_object_release(obj); >>>>>>> >>>>>>> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct >>>>>>> vm_area_struct *vma) >>>>>>> >>>>>>> err_close_vm: >>>>>>> drm_gem_vm_close(vma); >>>>>>> - drm_gem_free_mmap_offset(obj); >>>>>> >>>>>> Without previous patch, drm_gem_free_mmap_offset is required. I guess >>>>>> the reason you removed above line is that you thought >>>>>> drm_gem_object_release function would be called by drm_gem_vm_close >>>>>> function which drops a reference of the gem object. >>>>>> >>>>>> However, drm_gem_vm_close should be a pair with drm_gem_vm_open >>>>>> function. These will be called whenever a process opens or closes the >>>>>> VMA. So the reference count of the gem object had already been taken by >>>>>> open operation when a new reference to the VMA had been created. >>>>>> >>>>> >>>>> This changes is not related with drm_gem_vm_close and prior patch. Why >>>>> should free mmap offset when mmap operation is failed? The mmap offset >>>>> can be used repeatedly. >>>> >>>> Isn't vm space of vm manager still used even if any user-space process >>>> doesn't use the region? And if mmap is failed, then the user-space >>>> process will be terminated. Do you think it can be re-tried? However, >>>> mmap system call never return -EAGAIN. Is it reasonable to you? I cannot >>>> understand how the mmap offset can be re-used. So can you show me some >>>> example? >>>> >>> >>> Currently, mmap offset of exynos-drm gem is made by >>> DRM_IOCTL_MODE_MAP_DUMB ioctl and mmap() ioctl just uses the mmap >>> offset. User will use same mmap offset about same gem. It's why mmap >>> offset made by DRM_IOCTL_MODE_MAP_DUMB ioctl is unnecessary, it's just >>> enough to make mmap offset from when gem is create. You can get a >>> reference from drm_gem_cma_helper.c file. >> >> Hmm... It's not that the mmap offset can be re-used or not. It's that >> the mmap offset should be released or not when mmap failed. As your >> original comment, the call of drm_gem_free_mmap_offset() is unnecessary >> if mmap offset is created when gem creation because the mmap offset is >> removed by drm_gem_object_release() when gem is destroyed - gem should >> also be released when mmap failed. >> >> Ok, let's create mmap offset at gem creation and remove it gem >> releasing. Will merge these two patches. >> > > I can't find them from your git. Could you merge them? Oops, sorry. Merged. Thanks, Inki Dae > > Thanks. >
[PATCH 07/10] drm/exynos: add pm_runtime to FIMD
On 2015ë
09ì 05ì¼ 05:15, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Let pm_runtime handle the enabling/disabling of the device with proper
> refcnt instead of rely on specific flags to track the enabled state.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91
> +++
> 3 files changed, 37 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 79b2b22..838a9c1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
> .commit = decon_commit,
> .enable_vblank = decon_enable_vblank,
> .disable_vblank = decon_disable_vblank,
> - .commit = decon_commit,
Above wouldn't be related to this patch.
> .atomic_begin = decon_atomic_begin,
> .update_plane = decon_update_plane,
> .disable_plane = decon_disable_plane,
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index f3826dc..e4646e2 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
> .enable = decon_enable,
> .disable = decon_disable,
> .mode_fixup = decon_mode_fixup,
> - .commit = decon_commit,
Ditto.
Thanks,
Inki Dae
> .enable_vblank = decon_enable_vblank,
> .disable_vblank = decon_disable_vblank,
> .wait_for_vblank = decon_wait_for_vblank,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 0bbe537..0f17ae0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -160,7 +160,6 @@ struct fimd_context {
> u32 vidout_con;
> u32 i80ifcon;
> booli80_if;
> - boolsuspended;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> @@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc
> *crtc)
> struct fimd_context *ctx = crtc->ctx;
> u32 val;
>
> - if (ctx->suspended)
> - return -EPERM;
> -
> if (!test_and_set_bit(0, >irq_flags)) {
> val = readl(ctx->regs + VIDINTCON0);
>
> @@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc
> *crtc)
> struct fimd_context *ctx = crtc->ctx;
> u32 val;
>
> - if (ctx->suspended)
> - return;
> -
> if (test_and_clear_bit(0, >irq_flags)) {
> val = readl(ctx->regs + VIDINTCON0);
>
> @@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc
> *crtc)
> {
> struct fimd_context *ctx = crtc->ctx;
>
> - if (ctx->suspended)
> - return;
> -
> atomic_set(>wait_vsync_event, 1);
>
> /*
> @@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc
> *crtc)
> int pipe = ctx->pipe;
>
> /* ensure that vblank interrupt won't be reported to core */
> - ctx->suspended = false;
> ctx->pipe = -1;
>
> fimd_enable_vblank(ctx->crtc);
> fimd_wait_for_vblank(ctx->crtc);
> fimd_disable_vblank(ctx->crtc);
>
> - ctx->suspended = true;
> ctx->pipe = pipe;
> }
>
> @@ -394,9 +382,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
> void *timing_base = ctx->regs + driver_data->timing_base;
> u32 val, clkdiv;
>
> - if (ctx->suspended)
> - return;
> -
> /* nothing to do if we haven't set the mode yet */
> if (mode->htotal == 0 || mode->vtotal == 0)
> return;
> @@ -630,9 +615,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc
> *crtc,
> {
> struct fimd_context *ctx = crtc->ctx;
>
> - if (ctx->suspended)
> - return;
> -
> fimd_shadow_protect_win(ctx, plane->zpos, tr
[PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD
DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> +}
> +
> /**
> * shadow_protect_win() - disable updating values from shadow registers at
> vsync
> *
> @@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
> if (test_and_clear_bit(0, >irq_flags))
> fimd_enable_vblank(ctx->crtc);
>
> + fimd_dp_clock_enable(crtc, true);
You are forcing FIMD driver to enable DP clock every time FIMD is
enabled. Please know that in Exynos Display pipeline, Encoder device
could be used according to how Display path is configured.
For example,
FIMD - Panel
FIMD - MIPI-DSI - Panel
FIMD - DP - Panel
...
In previous codes, DP clock will be enabled by DP driver even through
enable callback of the DP clock is registered by FIMD driver to
fimd_crtc_ops, which means that DP clock can be enabled only in case
that DP driver is available.
Thanks,
Inki Dae
> +
> fimd_commit(ctx->crtc);
> }
>
> @@ -743,6 +762,8 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
> struct fimd_context *ctx = crtc->ctx;
> int i;
>
> + fimd_dp_clock_enable(crtc, false);
> +
> /*
>* We need to make sure that all windows are disabled before we
>* suspend that connector. Otherwise we might try to scan from
> @@ -814,23 +835,6 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
> drm_crtc_handle_vblank(>crtc->base);
> }
>
> -static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
> -{
> - struct fimd_context *ctx = crtc->ctx;
> - u32 val;
> -
> - /*
> - * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
> - * clock. On these SoCs the bootloader may enable it but any
> - * power domain off/on will reset it to disable state.
> - */
> - if (ctx->driver_data != _fimd_driver_data)
> - return;
> -
> - val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
> - writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> -}
> -
> static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
> .enable = fimd_enable,
> .disable = fimd_disable,
> @@ -843,7 +847,6 @@ static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
> .disable_plane = fimd_disable_plane,
> .atomic_flush = fimd_atomic_flush,
> .te_handler = fimd_te_handler,
> - .clock_enable = fimd_dp_clock_enable,
> };
>
> static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
>
[PATCH] drm/exynos: add cursor plane support
On 2015ë
09ì 04ì¼ 16:19, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
>> Hi Gustavo,
>>
>> I had already a review but I didn't give any comment to you. Sorry about
>> that. This patch looks good to me but one thing isn't clear. Below is my
>> comment.
>>
>>
>> On 2015ë
09ì 04ì¼ 05:14, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Set one of the planes for each crtc driver as a cursor plane enabled
>>> window managers to fully work on exynos.
>>>
>>> Signed-off-by: Gustavo Padovan
>>> ---
>>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 9 ++---
>>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
>>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 ++---
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++---
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
>>> 8 files changed, 31 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index b3c7307..79b2b22 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -33,7 +33,6 @@ struct decon_context {
>>> struct exynos_drm_plane planes[WINDOWS_NR];
>>> void __iomem*addr;
>>> struct clk *clks[6];
>>> - unsigned intdefault_win;
>>> unsigned long irq_flags;
>>> int pipe;
>>> boolsuspended;
>>> @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device
>>> *master, void *data)
>>> struct drm_device *drm_dev = data;
>>> struct exynos_drm_private *priv = drm_dev->dev_private;
>>> struct exynos_drm_plane *exynos_plane;
>>> - enum drm_plane_type type;
>>> unsigned int zpos;
>>> int ret;
>>>
>>> @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct
>>> device *master, void *data)
>>> ctx->pipe = priv->pipe++;
>>>
>>> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
>>> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
>>> - DRM_PLANE_TYPE_OVERLAY;
>>> ret = exynos_plane_init(drm_dev, >planes[zpos],
>>> - 1 << ctx->pipe, type, decon_formats,
>>> + 1 << ctx->pipe, decon_formats,
>>> ARRAY_SIZE(decon_formats), zpos);
>>> if (ret)
>>> return ret;
>>> }
>>>
>>> - exynos_plane = >planes[ctx->default_win];
>>> + exynos_plane = >planes[DEFAULT_WIN];
>>> ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>>> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>>> _crtc_ops, ctx);
>>> @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct
>>> platform_device *pdev)
>>> if (!ctx)
>>> return -ENOMEM;
>>>
>>> - ctx->default_win = 0;
>>> ctx->suspended = true;
>>> ctx->dev = dev;
>>> if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> index cbdb78e..f3826dc 100644
>>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> @@ -52,7 +52,6 @@ struct decon_context {
>>> struct clk *eclk;
>>> struct clk *vclk;
>>> void __iomem*regs;
>>> - unsigned intdefault_win;
>>> unsigned long irq_flags;
>>> booli80_if;
>>> boolsuspended;
>>> @@ -
[PATCH] drm/exynos: add cursor plane support
1 << ctx->pipe, type, decon_formats, > + 1 << ctx->pipe, decon_formats, > ARRAY_SIZE(decon_formats), zpos); > if (ret) > return ret; > } > > - exynos_plane = >planes[ctx->default_win]; > + exynos_plane = >planes[DEFAULT_WIN]; > ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base, > ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD, > _crtc_ops, ctx); > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h > b/drivers/gpu/drm/exynos/exynos_drm_drv.h > index b7ba21d..cc56c3d 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h > @@ -22,6 +22,9 @@ > #define MAX_PLANE5 > #define MAX_FB_BUFFER4 > > +#define DEFAULT_WIN 0 > +#define CURSOR_WIN 1 You fixed overlay number for cursor with 1. However, Display controllers of Exynos SoC have fixed overlay priority like this, win 4 > win 3 > win 2 > win 1 > win 0 so if we fix the overlay number for cursor and we use another overlay - which has a higher layer than cursor - to display caption or UI then the we couldn't see the cursor on screen without additional work such as color key or alpha channel. So before that, you need to check how many overlays can be used according to Exynos SoC versions, and which way is better - one is for top layer to be fixed for cursor, other is for one given layer to be fixed by user-space for cursor. Thanks, Inki Dae > +
[PATCH 6/9] drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers
On 2015ë
09ì 02ì¼ 05:35, Gustavo Padovan wrote:
> 2015-09-01 Joonyoung Shim :
>
>> This modifies exynos_drm_framebuffer_init() to be possible to support
>> multiple buffers. Then it can be used by exynos_user_fb_create().
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 36
>> +--
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 5 -
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 +--
>> 3 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 5cee148..8e5d3eb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -23,7 +23,6 @@
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> #include "exynos_drm_fbdev.h"
>> -#include "exynos_drm_gem.h"
>> #include "exynos_drm_iommu.h"
>> #include "exynos_drm_crtc.h"
>>
>> @@ -134,36 +133,41 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct
>> drm_framebuffer *fb)
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> -struct drm_gem_object *obj)
>> +struct exynos_drm_gem_obj **gem_obj,
>> +int count)
>> {
>> struct exynos_drm_fb *exynos_fb;
>> -struct exynos_drm_gem_obj *exynos_gem_obj;
>> +int i;
>> int ret;
>>
>> -exynos_gem_obj = to_exynos_gem_obj(obj);
>> -
>> -ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
>> -if (ret < 0)
>> -return ERR_PTR(ret);
>> -
>> exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
>> if (!exynos_fb)
>> return ERR_PTR(-ENOMEM);
>>
>> -drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
>> -exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;
>> +exynos_fb->buf_cnt = count;
>> +DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>>
>> -/* buffer count to framebuffer always is 1 at booting time. */
>> -exynos_fb->buf_cnt = 1;
>> +for (i = 0; i < count; i++) {
>> +ret = check_fb_gem_memory_type(dev, gem_obj[i]);
>> +if (ret < 0)
>> +goto err;
>> +
>> +exynos_fb->exynos_gem_obj[i] = gem_obj[i];
>> +}
>> +
>> +drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
>>
>> ret = drm_framebuffer_init(dev, _fb->fb, _drm_fb_funcs);
>> -if (ret) {
>> -kfree(exynos_fb);
>> +if (ret < 0) {
>> DRM_ERROR("failed to initialize framebuffer\n");
>> -return ERR_PTR(ret);
>> +goto err;
>> }
>>
>> return _fb->fb;
>> +
>> +err:
>> +kfree(exynos_fb);
>> +return ERR_PTR(ret);
>> }
>>
>> static struct drm_framebuffer *
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> index 897d2cf..8900f6b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> @@ -14,10 +14,13 @@
>> #ifndef _EXYNOS_DRM_FB_H_
>> #define _EXYNOS_DRM_FB_H
>>
>> +#include "exynos_drm_gem.h"
>> +
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> -struct drm_gem_object *obj);
>> +struct exynos_drm_gem_obj **gem_obj,
>> +int count);
>>
>> /* get gem object of a drm framebuffer */
>> struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct drm_framebuffer *fb,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index 133cf5f..a221f75 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -21,7 +21,6 @@
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> #include "exynos_drm_fbdev.h"
>> -#include "exynos_drm_gem.h"
>> #include "exynos_drm_iommu.h"
>>
>> #define MA
[PATCH 00/14] drm/exynos: rewrite fimg2d error handling
On 2015ë 08ì 28ì¼ 05:46, Tobias Jakobi wrote: > Hey Emil, > > > Emil Velikov wrote: >> Hi Tobias, >> >> On 24 August 2015 at 15:13, Tobias Jakobi >> wrote: >>> Hello, >>> >>> during the discussion about the last patchset touching the >>> fimg2d code, it became apparent that the error handling for >>> the command submission is currently unsatisfactory. >>> >>> This series rewrites the handling. All functions that submit >>> command buffers now first check if enough space is available >>> and only then proceed to build the command buffers. >>> >>> In particular the command buffer is no longer left in a >>> half-finished state, since parameters passed to the functions >>> are now validated before command submission. For this some >>> validation functions are introduced. >>> >>> This should also increase performance if the bottleneck is >>> the submission part, since adding commands to the buffer >>> is now more lightweight. >>> >>> Last but not least some prefix was added to messages printed >>> by fprintf and printf, and the G2D context struct was moved >>> out of the public header. >>> >>> >> Thanks for going with my earlier suggestion and untangling all this. >> >> I've went through the lot and it looks great afaict. Fwiw for the series >> Reviewed-by: Emil Velikov > thanks for the review and the help on IRC! > > >> As pretty much none of this is hardware specific and/or requires >> additional knowledge of the kernel module I'm inclined to pull this in >> even if we don't get too many reviewers. We better keep it around for >> a couple of weeks in case others are swamped with unrelated work atm, >> yet willing to take a look. > Sure, I'm going to wait and do some pings from time to time :) > I had a review and looks good to me. There are just cleanup issues but no problem to upstream them as-is. However, in my opinion, I think the patch 7 could be more cleaned up. Signed-off-by: Inki Dae Thanks, Inki Dae > > With best wishes, > Tobias > >> >> Cheers, >> Emil >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 04/14] exynos/fimg2d: check buffer space in g2d_solid_fill()
On 2015ë 09ì 01ì¼ 04:57, Emil Velikov wrote: > On 31 August 2015 at 20:27, Tobias Jakobi > wrote: >> Hello! >> >> Inki Dae wrote: >>> On 2015ë 08ì 24ì¼ 23:13, Tobias Jakobi wrote: > >>>> +if (g2d_check_space(ctx, 7, 1)) >>>> +return -ENOSPC; >>> >>> You can make 3 and 4 patches to one. These should be same patch. >> Hmm, so which 3 (respectively 4) patches should be squashed? >> > I believe he meant "squash the introduction of the function and its > uses into a single patch". > > Not sure how much value that brings, so I'll let you guys decide on > the bike shed colour :-) That - including relevant my comments - is just my opinion so no problem to upstream it as is. This is really trivial. Thanks, Inki Dae > > -Emil > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()
On 2015ë 09ì 01ì¼ 03:53, Emil Velikov wrote: > On 31 August 2015 at 14:25, Inki Dae wrote: >> On 2015ë 08ì 24ì¼ 23:14, Tobias Jakobi wrote: >>> We now validate the blending mode via g2d_validate_mode() >>> prior to feeding it to g2d_get_blend_op(). >>> >>> Signed-off-by: Tobias Jakobi >>> --- >>> exynos/exynos_fimg2d.c | 5 - >>> 1 file changed, 5 deletions(-) >>> >>> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c >>> index 4274a94..d708e91 100644 >>> --- a/exynos/exynos_fimg2d.c >>> +++ b/exynos/exynos_fimg2d.c >>> @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op) >>> SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0, >>> G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0); >>> break; >>> - default: >>> - fprintf(stderr, "Not support operation(%d).\n", op); >>> - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO, >>> - 0, 0, 0); >>> - break; >> >> With this, how about changing above switch and case statement to if >> statement? >> > Out of curiosity: why is if/else statement preferred - won't it make > things longer/harder to read (there are 11 cases here) ? Just looks strange to me switch and case statement has no default statement. This is just my opinion and trivial. Thanks, Inki Dae > > Cheers, > Emil > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
drm/exynos: add render node support
On 2015ë 09ì 01ì¼ 03:30, Emil Velikov wrote: > On 31 August 2015 at 13:36, Inki Dae wrote: >> Hi Emil, >> >> On 2015ë 08ì 31ì¼ 20:58, Emil Velikov wrote: >>> Hi all, >>> >>> On 18 August 2015 at 08:01, Inki Dae wrote: >>>> From: Joonyoung Shim >>>> >>>> This patch allows clients who want to use render node to access >>>> rendering relevant ioctls - g2d, post processor and gem allocation. >>>> >>> I seem to recall Dave and others saying that we must have users of >>> these interfaces prior to merging them into the kernel. Then again I >>> cannot find any open-source userspace using the post-processor. Can >>> anyone kingly share a link ? >> >> You can refer to the user-space below, >> https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e >> > Nice one thanks ! > Did those patch(es) ever made it to the list ? Mind giving them a tiny > bit of cleanup (move tests to exynos, drop duplication, C99 > initializers) and sending them over ? > > On a mildly related note: > The tizen people like excessive rebasing :( Another alternative would > be to send fixes upstream and keep their changes within ./packaging, > which will allow clean merges. I just shared the patch for you and someone who want to know the user-space of the post processor. The patch should be more __really__ cleaned up and refactored. After that, we'd like to post it to mainline in the near future. Currently, we are working on this in kernel and user-space side. > >>> >>> On the g2d front, can you guys take a look at the work Tobias has been >>> doing ? He seems to be the only one that cares about it :'( >> >> I'd like to say really sorry about that to you and Tobias. Will review >> it soon. >> > Great. Tobias sent a few more drm/exynos and libdrm (g2d utilities) > patches that've been around for a while :( > > Perhaps he can re-spin then and/or send a list with outstanding ones ? Ok, I will check it. Thanks, Inki Dae > > Cheers, > Emil >
[PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()
On 2015ë 08ì 24ì¼ 23:14, Tobias Jakobi wrote: > We now validate the blending mode via g2d_validate_mode() > prior to feeding it to g2d_get_blend_op(). > > Signed-off-by: Tobias Jakobi > --- > exynos/exynos_fimg2d.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c > index 4274a94..d708e91 100644 > --- a/exynos/exynos_fimg2d.c > +++ b/exynos/exynos_fimg2d.c > @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op) > SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0, > G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0); > break; > - default: > - fprintf(stderr, "Not support operation(%d).\n", op); > - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO, > - 0, 0, 0); > - break; With this, how about changing above switch and case statement to if statement? Thanks, Inki Dae > } > > return val.val; >
[PATCH 09/14] exynos/fimg2d: check buffer space in g2d_scale_and_blend()
On 2015ë
08ì 24ì¼ 23:14, Tobias Jakobi wrote:
> Apply the same transformation as in g2d_blend().
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 67
> +-
> 1 file changed, 39 insertions(+), 28 deletions(-)
>
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 5acccf8..4274a94 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -745,9 +745,47 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
> g2d_image *src,
> union g2d_point_val pt;
> union g2d_bitblt_cmd_val bitblt;
> union g2d_blend_func_val blend;
> - unsigned int scale;
> + unsigned int scale, gem_space;
> unsigned int scale_x, scale_y;
>
> + if (src_w == dst_w && src_h == dst_h)
> + scale = 0;
> + else {
> + scale = 1;
> + scale_x = g2d_get_scaling(src_w, dst_w);
> + scale_y = g2d_get_scaling(src_h, dst_h);
> + }
> +
> + if (src_x + src_w > src->width)
> + src_w = src->width - src_x;
> + if (src_y + src_h > src->height)
> + src_h = src->height - src_y;
> +
> + if (dst_x + dst_w > dst->width)
> + dst_w = dst->width - dst_x;
> + if (dst_y + dst_h > dst->height)
> + dst_h = dst->height - dst_y;
> +
> + if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
> + fprintf(stderr, "invalid width or height.\n");
> + return -EINVAL;
> + }
> +
> + if (g2d_validate_select_mode(src->select_mode)) {
> + fprintf(stderr , "invalid select mode for source.\n");
> + return -EINVAL;
> + }
> +
> + if (g2d_validate_blending_op(op)) {
> + fprintf(stderr , "unsupported blending operation.\n");
> + return -EINVAL;
> + }
> +
> + gem_space = src->select_mode == G2D_SELECT_MODE_NORMAL ? 2 : 1;
> +
> + if (g2d_check_space(ctx, 12 + scale * 3, gem_space))
> + return -ENOSPC;
Ditto.
Thanks,
Inki Dae
> +
> bitblt.val = 0;
> blend.val = 0;
>
> @@ -774,33 +812,6 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct
> g2d_image *src,
> case G2D_SELECT_MODE_BGCOLOR:
> g2d_add_cmd(ctx, BG_COLOR_REG, src->color);
> break;
> - default:
> - fprintf(stderr , "failed to set src.\n");
> - return -EINVAL;
> - }
> -
> - if (src_w == dst_w && src_h == dst_h)
> - scale = 0;
> - else {
> - scale = 1;
> - scale_x = g2d_get_scaling(src_w, dst_w);
> - scale_y = g2d_get_scaling(src_h, dst_h);
> - }
> -
> - if (src_x + src_w > src->width)
> - src_w = src->width - src_x;
> - if (src_y + src_h > src->height)
> - src_h = src->height - src_y;
> -
> - if (dst_x + dst_w > dst->width)
> - dst_w = dst->width - dst_x;
> - if (dst_y + dst_h > dst->height)
> - dst_h = dst->height - dst_y;
> -
> - if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
> - fprintf(stderr, "invalid width or height.\n");
> - g2d_reset(ctx);
> - return -EINVAL;
> }
>
> if (scale) {
>
[PATCH 08/14] exynos/fimg2d: check buffer space in g2d_blend()
On 2015ë
08ì 24ì¼ 23:14, Tobias Jakobi wrote:
> Move parameter validation to the top and also validate
> the select mode of the source image and the requested
> blending operation before starting command submission.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 66
> +-
> 1 file changed, 39 insertions(+), 27 deletions(-)
>
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 781aff5..5acccf8 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -623,7 +623,45 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
> union g2d_point_val pt;
> union g2d_bitblt_cmd_val bitblt;
> union g2d_blend_func_val blend;
> - unsigned int src_w = 0, src_h = 0, dst_w = 0, dst_h = 0;
> + unsigned int gem_space;
> + unsigned int src_w, src_h, dst_w, dst_h;
> +
> + src_w = w;
> + src_h = h;
> + if (src_x + w > src->width)
> + src_w = src->width - src_x;
> + if (src_y + h > src->height)
> + src_h = src->height - src_y;
> +
> + dst_w = w;
> + dst_h = h;
> + if (dst_x + w > dst->width)
> + dst_w = dst->width - dst_x;
> + if (dst_y + h > dst->height)
> + dst_h = dst->height - dst_y;
> +
> + w = MIN(src_w, dst_w);
> + h = MIN(src_h, dst_h);
> +
> + if (w <= 0 || h <= 0) {
> + fprintf(stderr, "invalid width or height.\n");
> + return -EINVAL;
> + }
> +
> + if (g2d_validate_select_mode(src->select_mode)) {
> + fprintf(stderr , "invalid select mode for source.\n");
> + return -EINVAL;
> + }
> +
> + if (g2d_validate_blending_op(op)) {
> + fprintf(stderr , "unsupported blending operation.\n");
> + return -EINVAL;
> + }
> +
> + gem_space = src->select_mode == G2D_SELECT_MODE_NORMAL ? 2 : 1;
> +
> + if (g2d_check_space(ctx, 12, gem_space))
> + return -ENOSPC;
As I mentioned before, above two lines could be integrated with other
patches.
Thanks,
Inki Dae
>
> bitblt.val = 0;
> blend.val = 0;
> @@ -651,32 +689,6 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
> case G2D_SELECT_MODE_BGCOLOR:
> g2d_add_cmd(ctx, BG_COLOR_REG, src->color);
> break;
> - default:
> - fprintf(stderr , "failed to set src.\n");
> - return -EINVAL;
> - }
> -
> - src_w = w;
> - src_h = h;
> - if (src_x + w > src->width)
> - src_w = src->width - src_x;
> - if (src_y + h > src->height)
> - src_h = src->height - src_y;
> -
> - dst_w = w;
> - dst_h = h;
> - if (dst_x + w > dst->width)
> - dst_w = dst->width - dst_x;
> - if (dst_y + h > dst->height)
> - dst_h = dst->height - dst_y;
> -
> - w = MIN(src_w, dst_w);
> - h = MIN(src_h, dst_h);
> -
> - if (w <= 0 || h <= 0) {
> - fprintf(stderr, "invalid width or height.\n");
> - g2d_reset(ctx);
> - return -EINVAL;
> }
>
> bitblt.data.alpha_blend_mode = G2D_ALPHA_BLEND_MODE_ENABLE;
>
[PATCH 07/14] exynos/fimg2d: add g2d_validate_xyz() functions
On 2015ë
08ì 24ì¼ 23:14, Tobias Jakobi wrote:
> The G2D headers define a number of modes through enums
> (like e.g. color, select, repeat, etc.).
>
> This introduces g2d_validate_select_mode() and
> g2d_validate_blending_op() which validate a
> select mode or blending operation respectively.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 44
> 1 file changed, 44 insertions(+)
>
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 2e04f4a..781aff5 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -119,6 +119,50 @@ static unsigned int g2d_check_space(const struct
> g2d_context *ctx,
> }
>
> /*
> + * g2d_validate_select_mode - validate select mode.
> + *
> + * @mode: the mode to validate
> + */
> +static unsigned int g2d_validate_select_mode(
> + enum e_g2d_select_mode mode)
> +{
> + switch (mode) {
> + case G2D_SELECT_MODE_NORMAL:
> + case G2D_SELECT_MODE_FGCOLOR:
> + case G2D_SELECT_MODE_BGCOLOR:
> + return 0;
> + }
It's strange use a bit. Just check the range like below,
First, please add G2D_SELECT_MODE_MAX which has 3 << 0, and
if (G2D_SELECT_MODE_MAX < mode) {
fprintf(strerr, "invalid command(0x%x)\n", mode);
return -EINVAL;
}
And I think it'd be better to change return type of this function to int,
> +
> + return 1;
so return 0
> +}
> +
> +/*
> + * g2d_validate_blending_op - validate blending operation.
> + *
> + * @operation: the operation to validate
> + */
> +static unsigned int g2d_validate_blending_op(
> + enum e_g2d_op operation)
> +{
> + switch (operation) {
> + case G2D_OP_CLEAR:
> + case G2D_OP_SRC:
> + case G2D_OP_DST:
> + case G2D_OP_OVER:
> + case G2D_OP_INTERPOLATE:
> + case G2D_OP_DISJOINT_CLEAR:
> + case G2D_OP_DISJOINT_SRC:
> + case G2D_OP_DISJOINT_DST:
> + case G2D_OP_CONJOINT_CLEAR:
> + case G2D_OP_CONJOINT_SRC:
> + case G2D_OP_CONJOINT_DST:
> + return 0;
Ditto, You could modify it like above.
Thanks,
Inki Dae
> + }
> +
> + return 1;
> +}
> +
> +/*
> * g2d_add_cmd - set given command and value to user side command buffer.
> *
> * @ctx: a pointer to g2d_context structure.
>
[PATCH 05/14] exynos/fimg2d: check buffer space in g2d_copy()
On 2015ë
08ì 24ì¼ 23:14, Tobias Jakobi wrote:
> Move the parameter validation before buffer space checking
> so that we can exit early if it fails.
> Also don't reset the G2D context anymore in this situation
> (since the buffers are not partially submitted).
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 9b7bcce..185aa80 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -375,17 +375,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
> {
> union g2d_rop4_val rop4;
> union g2d_point_val pt;
> - unsigned int src_w = 0, src_h = 0, dst_w = 0, dst_h = 0;
> -
> - g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
> - g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
> - g2d_add_base_addr(ctx, dst, g2d_dst);
> - g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
> -
> - g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
> - g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
> - g2d_add_base_addr(ctx, src, g2d_src);
> - g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
> + unsigned int src_w, src_h, dst_w, dst_h;
>
> src_w = w;
> src_h = h;
> @@ -406,10 +396,22 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
>
> if (w <= 0 || h <= 0) {
> fprintf(stderr, "invalid width or height.\n");
> - g2d_reset(ctx);
> return -EINVAL;
> }
>
> + if (g2d_check_space(ctx, 11, 2))
> + return -ENOSPC;
Above lines could be integrated with 3 and 4 patches as one patch. And
you can make other codes to other one.
Thanks,
Inki Dae
> +
> + g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
> + g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
> + g2d_add_base_addr(ctx, dst, g2d_dst);
> + g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
> +
> + g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
> + g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
> + g2d_add_base_addr(ctx, src, g2d_src);
> + g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
> +
> pt.val = 0;
> pt.data.x = src_x;
> pt.data.y = src_y;
>
[PATCH 04/14] exynos/fimg2d: check buffer space in g2d_solid_fill()
On 2015ë 08ì 24ì¼ 23:13, Tobias Jakobi wrote: > The amount of commands (regular and GEM) doesn't depend > on the input here. > > Signed-off-by: Tobias Jakobi > --- > exynos/exynos_fimg2d.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c > index 1ae8adf..9b7bcce 100644 > --- a/exynos/exynos_fimg2d.c > +++ b/exynos/exynos_fimg2d.c > @@ -319,6 +319,9 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image > *img, > union g2d_bitblt_cmd_val bitblt; > union g2d_point_val pt; > > + if (g2d_check_space(ctx, 7, 1)) > + return -ENOSPC; You can make 3 and 4 patches to one. These should be same patch. > + > g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_NORMAL); > g2d_add_cmd(ctx, DST_COLOR_MODE_REG, img->color_mode); > g2d_add_base_addr(ctx, img, g2d_dst); >
drm/exynos: add render node support
Hi Emil, On 2015ë 08ì 31ì¼ 20:58, Emil Velikov wrote: > Hi all, > > On 18 August 2015 at 08:01, Inki Dae wrote: >> From: Joonyoung Shim >> >> This patch allows clients who want to use render node to access >> rendering relevant ioctls - g2d, post processor and gem allocation. >> > I seem to recall Dave and others saying that we must have users of > these interfaces prior to merging them into the kernel. Then again I > cannot find any open-source userspace using the post-processor. Can > anyone kingly share a link ? You can refer to the user-space below, https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commit;h=52de1c57e2e6f3b2a1259478d5ae260ed4c5706e > > On the g2d front, can you guys take a look at the work Tobias has been > doing ? He seems to be the only one that cares about it :'( I'd like to say really sorry about that to you and Tobias. Will review it soon. Thanks, Inki Dae > > Thanks > Emil >
[PATCH] drm/exynos: fix exynos_drm_gem_prime_import_sg_table() error handling
2015-08-27 17:31 GMT+09:00 Joonyoung Shim :
> If exynos_drm_gem_init() is failed, the result is ERR_PTR, so we should
> just return the result. If not, wrong porinter will be referenced from
> err label.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 3e4a64a..4842a31 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -569,10 +569,8 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
> *dev,
> int ret;
>
> exynos_gem_obj = exynos_drm_gem_init(dev, attach->dmabuf->size);
> - if (IS_ERR(exynos_gem_obj)) {
> - ret = PTR_ERR(exynos_gem_obj);
> - goto err;
> - }
> + if (IS_ERR(exynos_gem_obj))
> + return exynos_gem_obj;
This patch incurs below build warning,
drivers/gpu/drm/exynos/exynos_drm_gem.c: In function
'exynos_drm_gem_prime_import_sg_table':
drivers/gpu/drm/exynos/exynos_drm_gem.c:670:3: warning: return from
incompatible pointer type [enabled by default]
We can simply return ERR_PTR(ret) and I just fixed it.
>
> exynos_gem_obj->dma_addr = sg_dma_address(sgt->sgl);
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/exynos: add prepare and cleanup phases for planes
On 2015ë
08ì 27ì¼ 00:45, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-24 Inki Dae :
>
>> On 2015ë
08ì 16ì¼ 01:26, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> .prepare_plane() and .cleanup_plane() allows to perform extra operations
>>> before and after the update of planes. For FIMD for example this will
>>> be used to enable disable the shadow protection bit.
>>>
>>> Signed-off-by: Gustavo Padovan
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 19 +++
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>> 2 files changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index 5a19e16..3a89fc9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -72,15 +72,34 @@ exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
>>> static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
>>> {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> + struct drm_plane *plane;
>>>
>>> if (crtc->state->event) {
>>> WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>>> exynos_crtc->event = crtc->state->event;
>>> }
>>> +
>>> + drm_atomic_crtc_for_each_plane(plane, crtc) {
>>> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>>> +
>>> + if (exynos_crtc->ops->prepare_plane)
>>> + exynos_crtc->ops->prepare_plane(exynos_crtc,
>>> + exynos_plane);
>>
>> There is no any reason to use prepare_plane/cleanup_plane callback
>> names. How about using atomic_begin/atomic_flush callback names instead
>> for consistency between framework and device drivers?
>
> Either names are fine for me. So let's go with atomic_begin/flush. I'll
> send an updated patchset.
Merged.
Thanks,
Inki Dae
>
> Gustavo
>
[PATCH 2/2] drm/exynos: implement atomic_{begin/flush} of FIMD and DECON
On 2015ë
08ì 20ì¼ 11:33, Hyungwon Hwang wrote:
> Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
> registers to active register in the functions. This patch achieves these
> purpose by moving the setting of protection bits to those functions from
> {fimd/decon}_update_plane.
Hyungwon,
Gustavo already posted atomic_begin/flush support. However, he didn't
consider decon drivers.
Can you post only atomic_begin/flush support for decon drivers?
Thanks,
Inki Dae
>
> Signed-off-by: Hyungwon Hwang
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 47 +---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 47
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51
> ++-
> 3 files changed, 103 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 484e312..fef0333 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -31,6 +31,7 @@ struct decon_context {
> struct drm_device *drm_dev;
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[WINDOWS_NR];
> + unsigned intupdated_plane;
> void __iomem*addr;
> struct clk *clks[6];
> unsigned intdefault_win;
> @@ -204,17 +205,17 @@ static void decon_win_set_pixfmt(struct decon_context
> *ctx, unsigned int win,
> writel(val, ctx->addr + DECON_WINCONx(win));
> }
>
> -static void decon_shadow_protect_win(struct decon_context *ctx, int win,
> - bool protect)
> +static void decon_shadow_protect_win(struct decon_context *ctx,
> + unsigned int win_bits, bool protect)
> {
> u32 val;
>
> val = readl(ctx->addr + DECON_SHADOWCON);
>
> if (protect)
> - val |= SHADOWCON_Wx_PROTECT(win);
> + val |= win_bits;
> else
> - val &= ~SHADOWCON_Wx_PROTECT(win);
> + val &= ~win_bits;
>
> writel(val, ctx->addr + DECON_SHADOWCON);
> }
> @@ -232,8 +233,6 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
> if (ctx->suspended)
> return;
>
> - decon_shadow_protect_win(ctx, win, true);
> -
> val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
> writel(val, ctx->addr + DECON_VIDOSDxA(win));
>
> @@ -265,15 +264,12 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
> val |= WINCONx_ENWIN_F;
> writel(val, ctx->addr + DECON_WINCONx(win));
>
> - decon_shadow_protect_win(ctx, win, false);
> -
> /* standalone update */
> val = readl(ctx->addr + DECON_UPDATE);
> val |= STANDALONE_UPDATE_F;
> writel(val, ctx->addr + DECON_UPDATE);
>
> - if (ctx->i80_if)
> - atomic_set(>win_updated, 1);
> + ctx->updated_plane |= SHADOWCON_Wx_PROTECT(win);
> }
>
> static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -286,14 +282,14 @@ static void decon_disable_plane(struct exynos_drm_crtc
> *crtc,
> if (ctx->suspended)
> return;
>
> - decon_shadow_protect_win(ctx, win, true);
> + decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), true);
>
> /* window disable */
> val = readl(ctx->addr + DECON_WINCONx(win));
> val &= ~WINCONx_ENWIN_F;
> writel(val, ctx->addr + DECON_WINCONx(win));
>
> - decon_shadow_protect_win(ctx, win, false);
> + decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), false);
>
> /* standalone update */
> val = readl(ctx->addr + DECON_UPDATE);
> @@ -405,6 +401,31 @@ void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
> drm_crtc_handle_vblank(>crtc->base);
> }
>
> +static void decon_begin(struct exynos_drm_crtc *crtc)
> +{
> + struct decon_context *ctx = crtc->ctx;
> + int i;
> + unsigned int val = 0;
> +
> + for (i = 0; i < WINDOWS_NR; i++)
> + val |= SHADOWCON_Wx_PROTECT(i);
> +
> + /* protect windows */
> + decon_shadow_protect_win(ctx, val, true);
> +}
> +
> +static void decon_flush(struct exynos_drm_crtc *crtc)
> +{
> + struct decon_context *ctx = crtc->ctx;
> +
> + if (ctx->updated_plane) {
> + decon_shadow_protect_win(ctx, ctx->updated_plane,
[PATCH 03/11] drm/exynos: add prepare and cleanup phases for planes
On 2015ë
08ì 16ì¼ 01:26, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> .prepare_plane() and .cleanup_plane() allows to perform extra operations
> before and after the update of planes. For FIMD for example this will
> be used to enable disable the shadow protection bit.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 19 +++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 5a19e16..3a89fc9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -72,15 +72,34 @@ exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
> static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
>
> if (crtc->state->event) {
> WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> exynos_crtc->event = crtc->state->event;
> }
> +
> + drm_atomic_crtc_for_each_plane(plane, crtc) {
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> +
> + if (exynos_crtc->ops->prepare_plane)
> + exynos_crtc->ops->prepare_plane(exynos_crtc,
> + exynos_plane);
There is no any reason to use prepare_plane/cleanup_plane callback
names. How about using atomic_begin/atomic_flush callback names instead
for consistency between framework and device drivers?
Thanks,
Inki Dae
> + }
> }
>
> static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
> {
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> +
> + drm_atomic_crtc_for_each_plane(plane, crtc) {
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> +
> + if (exynos_crtc->ops->cleanup_plane)
> + exynos_crtc->ops->cleanup_plane(exynos_crtc,
> + exynos_plane);
> + }
> }
>
> static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index a993aac..9f2b5c9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -87,6 +87,8 @@ struct exynos_drm_plane {
> * @disable_vblank: specific driver callback for disabling vblank interrupt.
> * @wait_for_vblank: wait for vblank interrupt to make sure that
> * hardware overlay is updated.
> + * @prepare_plane: prepare a window to receive a update
> + * @cleanup_plane: mark the end of a window update
> * @update_plane: apply hardware specific overlay data to registers.
> * @disable_plane: disable hardware specific overlay.
> * @te_handler: trigger to transfer video image at the tearing effect
> @@ -107,10 +109,14 @@ struct exynos_drm_crtc_ops {
> int (*enable_vblank)(struct exynos_drm_crtc *crtc);
> void (*disable_vblank)(struct exynos_drm_crtc *crtc);
> void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
> + void (*prepare_plane)(struct exynos_drm_crtc *crtc,
> + struct exynos_drm_plane *plane);
> void (*update_plane)(struct exynos_drm_crtc *crtc,
>struct exynos_drm_plane *plane);
> void (*disable_plane)(struct exynos_drm_crtc *crtc,
> struct exynos_drm_plane *plane);
> + void (*cleanup_plane)(struct exynos_drm_crtc *crtc,
> + struct exynos_drm_plane *plane);
> void (*te_handler)(struct exynos_drm_crtc *crtc);
> void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
> };
>
drm/exynos: add render node support
From: Joonyoung Shim <jy0922.s...@samsung.com>
This patch allows clients who want to use render node to access
rendering relevant ioctls - g2d, post processor and gem allocation.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 39 +
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7c65819..20800b3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -275,25 +275,25 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
+ DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
- exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
- vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
- exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST,
- exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
- exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY,
- exynos_drm_ipp_get_property, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY,
- exynos_drm_ipp_set_property, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF,
- exynos_drm_ipp_queue_buf, DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL,
- exynos_drm_ipp_cmd_ctrl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER, exynos_g2d_get_ver_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST, exynos_g2d_set_cmdlist_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
};
static const struct file_operations exynos_drm_driver_fops = {
@@ -310,7 +310,8 @@ static const struct file_operations exynos_drm_driver_fops
= {
};
static struct drm_driver exynos_drm_driver = {
- .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+ .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
+ DRIVER_RENDER,
.load = exynos_drm_load,
.unload = exynos_drm_unload,
.suspend= exynos_drm_suspend,
--
1.9.1
[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()
On 2015ë 08ì 17ì¼ 17:17, Joonyoung Shim wrote: > On 08/17/2015 04:52 PM, Inki Dae wrote: >> On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote: >>> On 08/16/2015 02:07 PM, Inki Dae wrote: >>>> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote: >>>>> The drm_gem_object_release() function already performs this cleanup, >>>>> so there is no reason to do it explicitly. >>>>> >>>>> Signed-off-by: Joonyoung Shim >>>>> --- >>>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- >>>>> 1 file changed, 3 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>> index c76aa8a..ab7d029 100644 >>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>>>> @@ -100,8 +100,6 @@ out: >>>>> exynos_drm_fini_buf(obj->dev, buf); >>>>> exynos_gem_obj->buffer = NULL; >>>>> >>>>> - drm_gem_free_mmap_offset(obj); >>>>> - >>>>> /* release file pointer to gem object. */ >>>>> drm_gem_object_release(obj); >>>>> >>>>> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct >>>>> vm_area_struct *vma) >>>>> >>>>> err_close_vm: >>>>> drm_gem_vm_close(vma); >>>>> - drm_gem_free_mmap_offset(obj); >>>> >>>> Without previous patch, drm_gem_free_mmap_offset is required. I guess >>>> the reason you removed above line is that you thought >>>> drm_gem_object_release function would be called by drm_gem_vm_close >>>> function which drops a reference of the gem object. >>>> >>>> However, drm_gem_vm_close should be a pair with drm_gem_vm_open >>>> function. These will be called whenever a process opens or closes the >>>> VMA. So the reference count of the gem object had already been taken by >>>> open operation when a new reference to the VMA had been created. >>>> >>> >>> This changes is not related with drm_gem_vm_close and prior patch. Why >>> should free mmap offset when mmap operation is failed? The mmap offset >>> can be used repeatedly. >> >> Isn't vm space of vm manager still used even if any user-space process >> doesn't use the region? And if mmap is failed, then the user-space >> process will be terminated. Do you think it can be re-tried? However, >> mmap system call never return -EAGAIN. Is it reasonable to you? I cannot >> understand how the mmap offset can be re-used. So can you show me some >> example? >> > > Currently, mmap offset of exynos-drm gem is made by > DRM_IOCTL_MODE_MAP_DUMB ioctl and mmap() ioctl just uses the mmap > offset. User will use same mmap offset about same gem. It's why mmap > offset made by DRM_IOCTL_MODE_MAP_DUMB ioctl is unnecessary, it's just > enough to make mmap offset from when gem is create. You can get a > reference from drm_gem_cma_helper.c file. Hmm... It's not that the mmap offset can be re-used or not. It's that the mmap offset should be released or not when mmap failed. As your original comment, the call of drm_gem_free_mmap_offset() is unnecessary if mmap offset is created when gem creation because the mmap offset is removed by drm_gem_object_release() when gem is destroyed - gem should also be released when mmap failed. Ok, let's create mmap offset at gem creation and remove it gem releasing. Will merge these two patches. Thanks, Inki Dae >
[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()
On 2015ë 08ì 17ì¼ 14:29, Joonyoung Shim wrote: > On 08/16/2015 02:07 PM, Inki Dae wrote: >> On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote: >>> The drm_gem_object_release() function already performs this cleanup, >>> so there is no reason to do it explicitly. >>> >>> Signed-off-by: Joonyoung Shim >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>> index c76aa8a..ab7d029 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c >>> @@ -100,8 +100,6 @@ out: >>> exynos_drm_fini_buf(obj->dev, buf); >>> exynos_gem_obj->buffer = NULL; >>> >>> - drm_gem_free_mmap_offset(obj); >>> - >>> /* release file pointer to gem object. */ >>> drm_gem_object_release(obj); >>> >>> @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct >>> vm_area_struct *vma) >>> >>> err_close_vm: >>> drm_gem_vm_close(vma); >>> - drm_gem_free_mmap_offset(obj); >> >> Without previous patch, drm_gem_free_mmap_offset is required. I guess >> the reason you removed above line is that you thought >> drm_gem_object_release function would be called by drm_gem_vm_close >> function which drops a reference of the gem object. >> >> However, drm_gem_vm_close should be a pair with drm_gem_vm_open >> function. These will be called whenever a process opens or closes the >> VMA. So the reference count of the gem object had already been taken by >> open operation when a new reference to the VMA had been created. >> > > This changes is not related with drm_gem_vm_close and prior patch. Why > should free mmap offset when mmap operation is failed? The mmap offset > can be used repeatedly. Isn't vm space of vm manager still used even if any user-space process doesn't use the region? And if mmap is failed, then the user-space process will be terminated. Do you think it can be re-tried? However, mmap system call never return -EAGAIN. Is it reasonable to you? I cannot understand how the mmap offset can be re-used. So can you show me some example? >
[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation
On 2015ë
08ì 17ì¼ 14:29, Joonyoung Shim wrote:
> On 08/16/2015 01:50 PM, Inki Dae wrote:
>> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>>> not, it will call drm_gem_create_mmap_offset whenever user requests
>>> DRM_IOCTL_MODE_MAP_DUMB ioctl.
>>
>> This patch makes drm_gem_create_mmap_offset to be called even in case of
>> not using dumb* interfaces. I.e.,
>> exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
>>
>
> I know mmap() of exynos-drm also needs mmap offset in drm_gem_mmap().
Ah, sorry. We already removed Exynos specific mmap ioctl. So we could
never use direct mapping ioctl anymore. I confused that.
>
>> And drm_gem_create_mmap_offset checks if vma_node was already allocated
>> or not so this patch doesn't make sense.
>>
>
> OK, but it calls drm_gem_create_mmap_offset still and will be returned
> after checking node->allocated. It's not unnecessary to me.
>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index 550d267..c76aa8a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct
>>> drm_device *dev,
>>> return ERR_PTR(ret);
>>> }
>>>
>>> + ret = drm_gem_create_mmap_offset(obj);
>>> + if (ret < 0) {
>>> + drm_gem_object_release(obj);
>>> + kfree(exynos_gem_obj);
>>> + return ERR_PTR(ret);
>>> + }
>>> +
>>> DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>>>
>>> return exynos_gem_obj;
>>> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file
>>> *file_priv,
>>> goto unlock;
>>> }
>>>
>>> - ret = drm_gem_create_mmap_offset(obj);
>>> - if (ret)
>>> - goto out;
>>> -
>>> *offset = drm_vma_node_offset_addr(>vma_node);
>>> DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>>>
>>> -out:
>>> drm_gem_object_unreference(obj);
>>> unlock:
>>> mutex_unlock(>struct_mutex);
>>>
>>
>>
>
>
[PATCH 13/14] drm/exynos: use prime helpers
On 2015ë
08ì 16ì¼ 14:26, Inki Dae wrote:
> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>> The dma-buf codes of exynos drm is almost same with prime helpers. A
>> difference is that consider DMA_NONE when import dma-buf, but it's wrong
>> and we don't consider it any more, so we can use prime interface.
>
> I think it's good idea to use prime helpers. However, I'm not sure of
> there really is no any corner case the prime helper doesn't consider for
> Vendor SoC yet. So let's have more reviews about this.
Just merged. We could consider something specific to Vendor SoC later
when that is clarified.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/Makefile| 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 289
>> -
>> drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 20 --
>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 9 +-
>> drivers/gpu/drm/exynos/exynos_drm_gem.c| 79
>> drivers/gpu/drm/exynos/exynos_drm_gem.h| 9 +
>> 6 files changed, 95 insertions(+), 313 deletions(-)
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
>>
>> diff --git a/drivers/gpu/drm/exynos/Makefile
>> b/drivers/gpu/drm/exynos/Makefile
>> index 7de0b10..95d0306 100644
>> --- a/drivers/gpu/drm/exynos/Makefile
>> +++ b/drivers/gpu/drm/exynos/Makefile
>> @@ -6,7 +6,7 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
>> exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
>> exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
>> exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
>> -exynos_drm_plane.o exynos_drm_dmabuf.o
>> +exynos_drm_plane.o
>>
>> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
>> exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> deleted file mode 100644
>> index 619ecdd..000
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> +++ /dev/null
>> @@ -1,289 +0,0 @@
>> -/* exynos_drm_dmabuf.c
>> - *
>> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>> - * Author: Inki Dae
>> - *
>> - * This program is free software; you can redistribute it and/or modify it
>> - * under the terms of the GNU General Public License as published by the
>> - * Free Software Foundation; either version 2 of the License, or (at your
>> - * option) any later version.
>> - */
>> -
>> -#include
>> -#include
>> -#include "exynos_drm_dmabuf.h"
>> -#include "exynos_drm_drv.h"
>> -#include "exynos_drm_gem.h"
>> -
>> -#include
>> -
>> -struct exynos_drm_dmabuf_attachment {
>> -struct sg_table *sgt;
>> -enum dma_data_direction dir;
>> -bool is_mapped;
>> -};
>> -
>> -static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
>> -{
>> -return to_exynos_gem_obj(buf->priv);
>> -}
>> -
>> -static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
>> -struct device *dev,
>> -struct dma_buf_attachment *attach)
>> -{
>> -struct exynos_drm_dmabuf_attachment *exynos_attach;
>> -
>> -exynos_attach = kzalloc(sizeof(*exynos_attach), GFP_KERNEL);
>> -if (!exynos_attach)
>> -return -ENOMEM;
>> -
>> -exynos_attach->dir = DMA_NONE;
>> -attach->priv = exynos_attach;
>> -
>> -return 0;
>> -}
>> -
>> -static void exynos_gem_detach_dma_buf(struct dma_buf *dmabuf,
>> -struct dma_buf_attachment *attach)
>> -{
>> -struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
>> -struct sg_table *sgt;
>> -
>> -if (!exynos_attach)
>> -return;
>> -
>> -sgt = exynos_attach->sgt;
>> -if (sgt) {
>> -if (exynos_attach->dir != DMA_NONE)
>> -dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> -exynos_attach->dir);
>> -sg_free_table(sgt);
>> -}
>> -
>> -kfree(sgt);
>> -kfree(exynos_attach);
>> -attach->priv = NULL;
>> -}
>> -
>
[PATCH 13/14] drm/exynos: use prime helpers
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The dma-buf codes of exynos drm is almost same with prime helpers. A
> difference is that consider DMA_NONE when import dma-buf, but it's wrong
> and we don't consider it any more, so we can use prime interface.
I think it's good idea to use prime helpers. However, I'm not sure of
there really is no any corner case the prime helper doesn't consider for
Vendor SoC yet. So let's have more reviews about this.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/Makefile| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 289
> -
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 20 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c| 9 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c| 79
> drivers/gpu/drm/exynos/exynos_drm_gem.h| 9 +
> 6 files changed, 95 insertions(+), 313 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
>
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 7de0b10..95d0306 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -6,7 +6,7 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
> exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
> exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
> exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
> - exynos_drm_plane.o exynos_drm_dmabuf.o
> + exynos_drm_plane.o
>
> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> deleted file mode 100644
> index 619ecdd..000
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ /dev/null
> @@ -1,289 +0,0 @@
> -/* exynos_drm_dmabuf.c
> - *
> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> - * Author: Inki Dae
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> - */
> -
> -#include
> -#include
> -#include "exynos_drm_dmabuf.h"
> -#include "exynos_drm_drv.h"
> -#include "exynos_drm_gem.h"
> -
> -#include
> -
> -struct exynos_drm_dmabuf_attachment {
> - struct sg_table *sgt;
> - enum dma_data_direction dir;
> - bool is_mapped;
> -};
> -
> -static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
> -{
> - return to_exynos_gem_obj(buf->priv);
> -}
> -
> -static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
> - struct device *dev,
> - struct dma_buf_attachment *attach)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach;
> -
> - exynos_attach = kzalloc(sizeof(*exynos_attach), GFP_KERNEL);
> - if (!exynos_attach)
> - return -ENOMEM;
> -
> - exynos_attach->dir = DMA_NONE;
> - attach->priv = exynos_attach;
> -
> - return 0;
> -}
> -
> -static void exynos_gem_detach_dma_buf(struct dma_buf *dmabuf,
> - struct dma_buf_attachment *attach)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> - struct sg_table *sgt;
> -
> - if (!exynos_attach)
> - return;
> -
> - sgt = exynos_attach->sgt;
> - if (sgt) {
> - if (exynos_attach->dir != DMA_NONE)
> - dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> - exynos_attach->dir);
> - sg_free_table(sgt);
> - }
> -
> - kfree(sgt);
> - kfree(exynos_attach);
> - attach->priv = NULL;
> -}
> -
> -static struct sg_table *
> - exynos_gem_map_dma_buf(struct dma_buf_attachment *attach,
> - enum dma_data_direction dir)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> - struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
> - struct exynos_drm_gem_buf *buf;
> - struct sg_table *sgt;
> - int npages;
> -
> - /* just return current sgt if already requested. */
> - if (exynos_attach->dir == dir && exynos_attach->is_mapped)
[PATCH 10/14] drm/exynos: remove function check_gem_flags
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The function check_gem_flags is too simple, so it's better to move codes
> in each consumer functions.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 24
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index ab7d029..03e85d8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -20,16 +20,6 @@
> #include "exynos_drm_buf.h"
> #include "exynos_drm_iommu.h"
>
> -static int check_gem_flags(unsigned int flags)
> -{
> - if (flags & ~(EXYNOS_BO_MASK)) {
> - DRM_ERROR("invalid flags.\n");
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
> struct vm_area_struct *vma)
> {
> @@ -169,6 +159,11 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
> drm_device *dev,
> struct exynos_drm_gem_buf *buf;
> int ret;
>
> + if (flags & ~(EXYNOS_BO_MASK)) {
> + DRM_ERROR("invalid flags.\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> if (!size) {
> DRM_ERROR("invalid size.\n");
> return ERR_PTR(-EINVAL);
> @@ -176,10 +171,6 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
> drm_device *dev,
>
> size = roundup_gem_size(size, flags);
>
> - ret = check_gem_flags(flags);
> - if (ret)
> - return ERR_PTR(ret);
> -
> buf = exynos_drm_init_buf(dev, size);
> if (!buf)
> return ERR_PTR(-ENOMEM);
> @@ -584,9 +575,10 @@ int exynos_drm_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> obj = vma->vm_private_data;
> exynos_gem_obj = to_exynos_gem_obj(obj);
>
> - ret = check_gem_flags(exynos_gem_obj->flags);
> - if (ret)
> + if (exynos_gem_obj->flags & ~(EXYNOS_BO_MASK)) {
> + DRM_ERROR("invalid flags.\n");
> goto err_close_vm;
> + }
I will remove above checking as Daniel Stone commented because user
space cannot control the flag.
Thanks,
Inki Dae
>
> update_vm_cache_attr(exynos_gem_obj, vma);
>
>
[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()
On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote: > The drm_gem_object_release() function already performs this cleanup, > so there is no reason to do it explicitly. > > Signed-off-by: Joonyoung Shim > --- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c > b/drivers/gpu/drm/exynos/exynos_drm_gem.c > index c76aa8a..ab7d029 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c > @@ -100,8 +100,6 @@ out: > exynos_drm_fini_buf(obj->dev, buf); > exynos_gem_obj->buffer = NULL; > > - drm_gem_free_mmap_offset(obj); > - > /* release file pointer to gem object. */ > drm_gem_object_release(obj); > > @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct > vm_area_struct *vma) > > err_close_vm: > drm_gem_vm_close(vma); > - drm_gem_free_mmap_offset(obj); Without previous patch, drm_gem_free_mmap_offset is required. I guess the reason you removed above line is that you thought drm_gem_object_release function would be called by drm_gem_vm_close function which drops a reference of the gem object. However, drm_gem_vm_close should be a pair with drm_gem_vm_open function. These will be called whenever a process opens or closes the VMA. So the reference count of the gem object had already been taken by open operation when a new reference to the VMA had been created. Thanks, Inki Dae > > return ret; > } >
[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
> not, it will call drm_gem_create_mmap_offset whenever user requests
> DRM_IOCTL_MODE_MAP_DUMB ioctl.
This patch makes drm_gem_create_mmap_offset to be called even in case of
not using dumb* interfaces. I.e.,
exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
And drm_gem_create_mmap_offset checks if vma_node was already allocated
or not so this patch doesn't make sense.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 550d267..c76aa8a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> + ret = drm_gem_create_mmap_offset(obj);
> + if (ret < 0) {
> + drm_gem_object_release(obj);
> + kfree(exynos_gem_obj);
> + return ERR_PTR(ret);
> + }
> +
> DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>
> return exynos_gem_obj;
> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file
> *file_priv,
> goto unlock;
> }
>
> - ret = drm_gem_create_mmap_offset(obj);
> - if (ret)
> - goto out;
> -
> *offset = drm_vma_node_offset_addr(>vma_node);
> DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>
> -out:
> drm_gem_object_unreference(obj);
> unlock:
> mutex_unlock(>struct_mutex);
>
[PATCH 02/14] drm/exynos: remove function convert_to_vm_err_msg
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The convert_to_vm_err_msg is called just once by exynos_drm_gem_fault,
> so it's simple not to use the function.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 33
> +
> 1 file changed, 9 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index d320acd..752cb7c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -20,29 +20,6 @@
> #include "exynos_drm_buf.h"
> #include "exynos_drm_iommu.h"
>
> -static unsigned int convert_to_vm_err_msg(int msg)
> -{
> - unsigned int out_msg;
> -
> - switch (msg) {
> - case 0:
> - case -ERESTARTSYS:
> - case -EINTR:
> - out_msg = VM_FAULT_NOPAGE;
> - break;
> -
> - case -ENOMEM:
> - out_msg = VM_FAULT_OOM;
> - break;
> -
> - default:
> - out_msg = VM_FAULT_SIGBUS;
> - break;
> - }
> -
> - return out_msg;
> -}
> -
> static int check_gem_flags(unsigned int flags)
> {
> if (flags & ~(EXYNOS_BO_MASK)) {
> @@ -600,7 +577,15 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf)
>
> mutex_unlock(>struct_mutex);
>
> - return convert_to_vm_err_msg(ret);
> + switch (ret) {
> + case 0:
> + case -ERESTARTSYS:
You missed -EINTR but I can modify it.
Thanks,
Inki Dae
> + return VM_FAULT_NOPAGE;
> + case -ENOMEM:
> + return VM_FAULT_OOM;
> + default:
> + return VM_FAULT_SIGBUS;
> + }
> }
>
> int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>
[PATCH] drm: make sure to check callbacks of ENCODER and CRTC helpers
This patch fixes NULL pointer access issues to ENCODER
and CRTC drivers.
Vendor specific DRM KMS drivers may not set their helper callbacks
to ENCODER dn CRTC drivers. In this case, that will incur NULL
pointer access when modeset is tried.
So this patch makes sure to check if the callbacks are NULL or not.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_crtc_helper.c | 44 ++-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ef53475..aa1f42f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -318,16 +318,22 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
}
encoder_funcs = encoder->helper_private;
- if (!(ret = encoder_funcs->mode_fixup(encoder, mode,
- adjusted_mode))) {
- DRM_DEBUG_KMS("Encoder fixup failed\n");
- goto done;
+ if (encoder_funcs->mode_fixup) {
+ ret = encoder_funcs->mode_fixup(encoder, mode,
+ adjusted_mode);
+ if (!ret) {
+ DRM_DEBUG_KMS("Encoder fixup failed\n");
+ goto done;
+ }
}
}
- if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
- DRM_DEBUG_KMS("CRTC fixup failed\n");
- goto done;
+ if (crtc_funcs->mode_fixup) {
+ ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode);
+ if (!ret) {
+ DRM_DEBUG_KMS("CRTC fixup failed\n");
+ goto done;
+ }
}
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
@@ -343,21 +349,26 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
encoder_funcs = encoder->helper_private;
/* Disable the encoders as the first thing we do. */
- encoder_funcs->prepare(encoder);
+ if (encoder_funcs->prepare)
+ encoder_funcs->prepare(encoder);
drm_bridge_post_disable(encoder->bridge);
}
drm_crtc_prepare_encoders(dev);
- crtc_funcs->prepare(crtc);
+ if (crtc_funcs->prepare)
+ crtc_funcs->prepare(crtc);
/* Set up the DPLL and any encoders state that needs to adjust or depend
* on the DPLL.
*/
- ret = !crtc_funcs->mode_set(crtc, mode, adjusted_mode, x, y, old_fb);
- if (!ret)
- goto done;
+ if (crtc_funcs->mode_set) {
+ ret = !crtc_funcs->mode_set(crtc, mode, adjusted_mode, x, y,
+ old_fb);
+ if (!ret)
+ goto done;
+ }
drm_for_each_encoder(encoder, dev) {
@@ -368,13 +379,15 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
encoder->base.id, encoder->name,
mode->base.id, mode->name);
encoder_funcs = encoder->helper_private;
- encoder_funcs->mode_set(encoder, mode, adjusted_mode);
+ if (encoder_funcs->mode_set)
+ encoder_funcs->mode_set(encoder, mode, adjusted_mode);
drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
}
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
- crtc_funcs->commit(crtc);
+ if (crtc_funcs->commit)
+ crtc_funcs->commit(crtc);
drm_for_each_encoder(encoder, dev) {
@@ -384,7 +397,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
drm_bridge_pre_enable(encoder->bridge);
encoder_funcs = encoder->helper_private;
- encoder_funcs->commit(encoder);
+ if (encoder_funcs->commit)
+ encoder_funcs->commit(encoder);
drm_bridge_enable(encoder->bridge);
}
--
1.9.1
[PATCH] drm/atomic: do not call ww_acquire_done in drm_atomic_check_only
This patch fixes warning case when two more crtc driver are enabled and two more atomic checking are tried at booting time. With fbcon, modeset operation is performed at booting time. In this case, if two mode crtc drivers are enabled, then drm_atomic_check_only function will be called by restore_fbdev_mode function - the value of fb_helper->crtc_count is bigger than 1 - two more times. So that will incur warning by below line of ww_acquire_done, DEBUG_LOCKS_WARN_ON(ctx->done_acquire); ctx->done_acquire = 1; ctx->done_acquire became 1 when drm_mode_set_config_internal for first crtc driver was called, and then ctx->done_acquire becomes 2 when drm_mode_set_con_internal for second crtc driver was called. So the function, ww_acqure_done(), should be called at more top function than at drm_atomic_check_only() to make sure that no one tries to acquire more locks. Signed-off-by: Inki Dae --- drivers/gpu/drm/drm_atomic.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 1066e4b..4349154 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1230,9 +1230,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } - if (ret == 0) - ww_acquire_done(>acquire_ctx->ww_ctx); - return ret; } EXPORT_SYMBOL(drm_atomic_check_only); -- 1.9.1
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
2015-08-13 0:54 GMT+09:00 Gustavo Padovan : > 2015-08-12 Gustavo Padovan : > >> Hi Inki, >> >> 2015-08-11 Inki Dae : >> >> > On 2015ë 08ì 11ì¼ 09:38, Gustavo Padovan wrote: >> > > Hi Inki, >> > > >> > > 2015-08-07 Inki Dae : >> > > >> > >> Hi Gustavo, >> > >> >> > >> On 2015ë 08ì 06ì¼ 22:31, Gustavo Padovan wrote: >> > >>> From: Gustavo Padovan >> > >>> >> > >>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it >> > >>> had >> > >>> only a drm_encoder member and the internal exynos_drm_encoders ops that >> > >>> was directly mapped to the drm_encoder helper funcs. >> > >>> >> > >>> So now exynos DRM uses struct drm_encoder directly, this removes >> > >>> completely the struct exynos_drm_encoder. >> > >>> >> > >> >> > >> Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch >> > >> is applied. Below is the booting logs, >> > >> [1.171318] console [ttySAC2] enabled >> > >> [1.175522] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 60, >> > >> base_baud = 0) is a S3C6400/10 >> > >> [1.185545] [drm] Initialized drm 1.1.0 20060810 >> > >> [1.194104] exynos-drm exynos-drm: bound 11c0.fimd (ops >> > >> fimd_component_ops) >> > >> [1.200352] exynos-drm exynos-drm: bound 11c8.dsi (ops >> > >> exynos_dsi_component_ops) >> > >> [1.207688] [drm] Supports vblank timestamp caching Rev 2 >> > >> (21.10.2013). >> > >> [1.214313] [drm] No driver support for vblank timestamp query. >> > >> [1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >> > >> >> > >> Booting is locked up here. This patch looks good to me so I tried to >> > >> find why locked up and I found the booting is locked up as soon as >> > >> console_lock function is called. Can you and other guys look into this >> > >> issue? >> > > >> > > I've realized that I left a fix for patch 01 behind, it could be the >> > > cause of this issue. I've just resent this patch with the added v2 fix >> > > up. >> > >> > With above change, still locked up. So your updated patch doesn't >> > resolve this issue. >> > >> > Anyway, I tested it with fbdev emulation relevant patch series[1] and >> > the booting was ok with disabling fbdev emulation as Daniel commented. >> > However, I think the booting should also be ok with fbdev emulation so I >> > don't want for your last patch to be merged to mainline until the issue >> > is resolved. >> >> I've tried to reproduce your issue with these patches on a odroid-x2 >> (exynos4412) but it seems to work fine for me with fbdev emulation >> enabled. In snow and peach-pi it also works fine. We would need >> to debug better on your side to figure out what is breaking for you. > > Can you please git bisect this? So we can figure out which commit is > causing the issue. That would be great. I already commented above, your last patch - 11/11. Without 11/11, it worked well. Did you test odroid-x2 with LVDS based Display panel? If so, it's not different because I tested it with Trats2 board with MIPI-DSI + Display panel. AFAIK, Odroid-x2 board doesn't support MIPI-DSI panel. I will have a pull request soon without 11/11. After that, I think we could find and resolve the issue later. Thanks, Inki Dae > > Gustavo > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
On 2015ë 08ì 12ì¼ 00:03, Daniel Vetter wrote: > On Tue, Aug 11, 2015 at 09:13:54PM +0900, Inki Dae wrote: >> On 2015ë 08ì 11ì¼ 09:38, Gustavo Padovan wrote: >>> Hi Inki, >>> >>> 2015-08-07 Inki Dae : >>> >>>> Hi Gustavo, >>>> >>>> On 2015ë 08ì 06ì¼ 22:31, Gustavo Padovan wrote: >>>>> From: Gustavo Padovan >>>>> >>>>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had >>>>> only a drm_encoder member and the internal exynos_drm_encoders ops that >>>>> was directly mapped to the drm_encoder helper funcs. >>>>> >>>>> So now exynos DRM uses struct drm_encoder directly, this removes >>>>> completely the struct exynos_drm_encoder. >>>>> >>>> >>>> Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch >>>> is applied. Below is the booting logs, >>>> [1.171318] console [ttySAC2] enabled >>>> [1.175522] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 60, >>>> base_baud = 0) is a S3C6400/10 >>>> [1.185545] [drm] Initialized drm 1.1.0 20060810 >>>> [1.194104] exynos-drm exynos-drm: bound 11c0.fimd (ops >>>> fimd_component_ops) >>>> [1.200352] exynos-drm exynos-drm: bound 11c8.dsi (ops >>>> exynos_dsi_component_ops) >>>> [1.207688] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >>>> [1.214313] [drm] No driver support for vblank timestamp query. >>>> [1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >>>> >>>> Booting is locked up here. This patch looks good to me so I tried to >>>> find why locked up and I found the booting is locked up as soon as >>>> console_lock function is called. Can you and other guys look into this >>>> issue? >>> >>> I've realized that I left a fix for patch 01 behind, it could be the >>> cause of this issue. I've just resent this patch with the added v2 fix >>> up. >> >> With above change, still locked up. So your updated patch doesn't >> resolve this issue. >> >> Anyway, I tested it with fbdev emulation relevant patch series[1] and >> the booting was ok with disabling fbdev emulation as Daniel commented. >> However, I think the booting should also be ok with fbdev emulation so I >> don't want for your last patch to be merged to mainline until the issue >> is resolved. > > Without fbdev you need to start a kms client (X, whatever) to force a Of course I know. Without fbdev, modeset never be performed at booting time. However, without fbdev, we cannot use text console and that is definitely a problem. Thanks, Inki Dae > modeset. Otherwise you won't reproduce anything. And sometimes it requires > a bit of trickery to create a sequence of modeset calls which exactly > match what fbcon would do. > -Daniel > >> >> [1] http://www.spinics.net/lists/dri-devel/msg86617.html >> http://lists.freedesktop.org/archives/dri-devel/2015-March/078975.html >> >> Thanks, >> Inki Dae >> >>> >>> Gustavo >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-samsung-soc" in >>> the body of a message to majordomo at vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request fixes memory leak and some issues related to mixer and gscaler driver issues. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit bdce3e7c729907e303396690b2b23b972c6717be: Merge branch 'msm-fixes-4.2' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2015-07-30 12:41:44 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to 9992349a54823c511acc438364dceda7abe4ac98: drm/exynos/fimc: fix runtime pm support (2015-08-11 17:21:35 +0900) Andrzej Hajda (4): drm/exynos/hdmi: fix edid memory leak drm/exynos/mixer: fix interrupt clearing drm/exynos/mixer: correct vsync configuration sequence drm/exynos/mixer: always update INT_EN cache Hyungwon Hwang (1): drm/exynos: gsc: fix wrong bitwise operation for swap detection Marek Szyprowski (1): drm/exynos/fimc: fix runtime pm support drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 - drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++- drivers/gpu/drm/exynos/exynos_mixer.c| 21 ++--- 4 files changed, 22 insertions(+), 13 deletions(-)
[PATCH v2 14/25] drm/exynos: Use new drm_fb_helper functions
On 2015ë
07ì 22ì¼ 15:59, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 47
> ---
> 1 file changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index e0b085b..dd64bc0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -65,9 +65,9 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
> static struct fb_ops exynos_drm_fb_ops = {
> .owner = THIS_MODULE,
> .fb_mmap= exynos_drm_fb_mmap,
> - .fb_fillrect= cfb_fillrect,
> - .fb_copyarea= cfb_copyarea,
> - .fb_imageblit = cfb_imageblit,
> + .fb_fillrect= drm_fb_helper_cfb_fillrect,
> + .fb_copyarea= drm_fb_helper_cfb_copyarea,
> + .fb_imageblit = drm_fb_helper_cfb_imageblit,
> .fb_check_var = drm_fb_helper_check_var,
> .fb_set_par = drm_fb_helper_set_par,
> .fb_blank = drm_fb_helper_blank,
> @@ -142,10 +142,10 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
>
> mutex_lock(>struct_mutex);
>
> - fbi = framebuffer_alloc(0, >dev);
> - if (!fbi) {
> + fbi = drm_fb_helper_alloc_fbi(helper);
> + if (IS_ERR(fbi)) {
> DRM_ERROR("failed to allocate fb info.\n");
> - ret = -ENOMEM;
> + ret = PTR_ERR(fbi);
> goto out;
> }
>
> @@ -165,7 +165,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
>
> if (IS_ERR(exynos_gem_obj)) {
> ret = PTR_ERR(exynos_gem_obj);
> - goto err_release_framebuffer;
> + goto err_release_fbi;
> }
>
> exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
> @@ -178,33 +178,23 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> goto err_destroy_gem;
> }
>
> - helper->fbdev = fbi;
> -
> fbi->par = helper;
> fbi->flags = FBINFO_FLAG_DEFAULT;
> fbi->fbops = _drm_fb_ops;
>
> - ret = fb_alloc_cmap(>cmap, 256, 0);
> - if (ret) {
> - DRM_ERROR("failed to allocate cmap.\n");
> - goto err_destroy_framebuffer;
> - }
> -
> ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
> if (ret < 0)
> - goto err_dealloc_cmap;
> + goto err_destroy_framebuffer;
>
> mutex_unlock(>struct_mutex);
> return ret;
>
> -err_dealloc_cmap:
> - fb_dealloc_cmap(>cmap);
> err_destroy_framebuffer:
> drm_framebuffer_cleanup(helper->fb);
> err_destroy_gem:
> exynos_drm_gem_destroy(exynos_gem_obj);
> -err_release_framebuffer:
> - framebuffer_release(fbi);
> +err_release_fbi:
> + drm_fb_helper_release_fbi(helper);
>
> /*
> * if failed, all resources allocated above would be released by
> @@ -312,21 +302,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device
> *dev,
> }
> }
>
> - /* release linux framebuffer */
> - if (fb_helper->fbdev) {
> - struct fb_info *info;
> - int ret;
> -
> - info = fb_helper->fbdev;
> - ret = unregister_framebuffer(info);
> - if (ret < 0)
> - DRM_DEBUG_KMS("failed unregister_framebuffer()\n");
> -
> - if (info->cmap.len)
> - fb_dealloc_cmap(>cmap);
> -
> - framebuffer_release(info);
> - }
> + drm_fb_helper_unregister_fbi(fb_helper);
> + drm_fb_helper_release_fbi(fb_helper);
>
> drm_fb_helper_fini(fb_helper);
> }
>
[PATCH v2] drm/atomic: fix null pointer access to mode_fixup callback
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Changelog v2:
- change it to else if
Signed-off-by: Inki Dae
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 5b59d5ad..c25bacb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -298,7 +298,7 @@ mode_fixup(struct drm_atomic_state *state)
encoder->base.id,
encoder->name);
return ret;
}
- } else {
+ } else if (funcs->mode_fixup) {
ret = funcs->mode_fixup(encoder, _state->mode,
_state->adjusted_mode);
if (!ret) {
--
1.9.1
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
On 2015ë 08ì 11ì¼ 09:38, Gustavo Padovan wrote: > Hi Inki, > > 2015-08-07 Inki Dae : > >> Hi Gustavo, >> >> On 2015ë 08ì 06ì¼ 22:31, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had >>> only a drm_encoder member and the internal exynos_drm_encoders ops that >>> was directly mapped to the drm_encoder helper funcs. >>> >>> So now exynos DRM uses struct drm_encoder directly, this removes >>> completely the struct exynos_drm_encoder. >>> >> >> Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch >> is applied. Below is the booting logs, >> [1.171318] console [ttySAC2] enabled >> [1.175522] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 60, >> base_baud = 0) is a S3C6400/10 >> [1.185545] [drm] Initialized drm 1.1.0 20060810 >> [1.194104] exynos-drm exynos-drm: bound 11c0.fimd (ops >> fimd_component_ops) >> [1.200352] exynos-drm exynos-drm: bound 11c8.dsi (ops >> exynos_dsi_component_ops) >> [1.207688] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [1.214313] [drm] No driver support for vblank timestamp query. >> [1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >> >> Booting is locked up here. This patch looks good to me so I tried to >> find why locked up and I found the booting is locked up as soon as >> console_lock function is called. Can you and other guys look into this >> issue? > > I've realized that I left a fix for patch 01 behind, it could be the > cause of this issue. I've just resent this patch with the added v2 fix > up. With above change, still locked up. So your updated patch doesn't resolve this issue. Anyway, I tested it with fbdev emulation relevant patch series[1] and the booting was ok with disabling fbdev emulation as Daniel commented. However, I think the booting should also be ok with fbdev emulation so I don't want for your last patch to be merged to mainline until the issue is resolved. [1] http://www.spinics.net/lists/dri-devel/msg86617.html http://lists.freedesktop.org/archives/dri-devel/2015-March/078975.html Thanks, Inki Dae > > Gustavo > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] drm/atomic: fix null pointer access to mode_fixup callback
This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.
mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 5b59d5ad..b69469c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -299,6 +299,9 @@ mode_fixup(struct drm_atomic_state *state)
return ret;
}
} else {
+ if (!funcs->mode_fixup)
+ continue;
+
ret = funcs->mode_fixup(encoder, _state->mode,
_state->adjusted_mode);
if (!ret) {
--
1.9.1
[PATCH 14/25] drm/exynos: Use new drm_fb_helper functions
On 2015ë
08ì 11ì¼ 18:04, Inki Dae wrote:
> On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
>> Use the newly created wrapper drm_fb_helper functions instead of calling
>> core fbdev functions directly. They also simplify the fb_info creation.
>>
>> COMPILE TESTED ONLY.
>>
>> Cc: Inki Dae
>> Cc: Joonyoung Shim
>> Cc: Seung-Woo Kim
>>
>> Signed-off-by: Archit Taneja
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 45
>> +--
>> 1 file changed, 12 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index e0b085b..6975b70 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -65,9 +65,9 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
>> static struct fb_ops exynos_drm_fb_ops = {
>> .owner = THIS_MODULE,
>> .fb_mmap= exynos_drm_fb_mmap,
>> -.fb_fillrect= cfb_fillrect,
>> -.fb_copyarea= cfb_copyarea,
>> -.fb_imageblit = cfb_imageblit,
>> +.fb_fillrect= drm_fb_helper_cfb_fillrect,
>> +.fb_copyarea= drm_fb_helper_cfb_copyarea,
>> +.fb_imageblit = drm_fb_helper_cfb_imageblit,
>> .fb_check_var = drm_fb_helper_check_var,
>> .fb_set_par = drm_fb_helper_set_par,
>> .fb_blank = drm_fb_helper_blank,
>> @@ -142,10 +142,10 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper,
>>
>> mutex_lock(>struct_mutex);
>>
>> -fbi = framebuffer_alloc(0, >dev);
>> -if (!fbi) {
>> +fbi = drm_fb_helper_alloc_fbi(helper);
>> +if (IS_ERR(fbi)) {
>> DRM_ERROR("failed to allocate fb info.\n");
>> -ret = -ENOMEM;
>> +ret = PTR_ERR(fbi);
>> goto out;
>> }
>>
>> @@ -165,7 +165,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
>> *helper,
>>
>> if (IS_ERR(exynos_gem_obj)) {
>> ret = PTR_ERR(exynos_gem_obj);
>> -goto err_release_framebuffer;
>> +goto err_release_fbi;
>> }
>>
>> exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
>> @@ -178,21 +178,13 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper,
>> goto err_destroy_gem;
>> }
>>
>> -helper->fbdev = fbi;
>> -
>> fbi->par = helper;
>> fbi->flags = FBINFO_FLAG_DEFAULT;
>> fbi->fbops = _drm_fb_ops;
>>
>> -ret = fb_alloc_cmap(>cmap, 256, 0);
>> -if (ret) {
>> -DRM_ERROR("failed to allocate cmap.\n");
>> -goto err_destroy_framebuffer;
>> -}
>> -
>> ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
>> if (ret < 0)
>> -goto err_dealloc_cmap;
>> +goto err_destroy_framebuffer;
>
> With above change, err_dealloc_cmap label isn't used anymore so you need
> to remove below lines,
>
> err_dealloc_cmap:
> fb_dealloc_cmap(>cmap);
Oops, Sorry. You already posted v2 and there is no warning.
Please ignore it.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> mutex_unlock(>struct_mutex);
>> return ret;
>> @@ -203,8 +195,8 @@ err_destroy_framebuffer:
>> drm_framebuffer_cleanup(helper->fb);
>> err_destroy_gem:
>> exynos_drm_gem_destroy(exynos_gem_obj);
>> -err_release_framebuffer:
>> -framebuffer_release(fbi);
>> +err_release_fbi:
>> +drm_fb_helper_release_fbi(helper);
>>
>> /*
>> * if failed, all resources allocated above would be released by
>> @@ -312,21 +304,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device
>> *dev,
>> }
>> }
>>
>> -/* release linux framebuffer */
>> -if (fb_helper->fbdev) {
>> -struct fb_info *info;
>> -int ret;
>> -
>> -info = fb_helper->fbdev;
>> -ret = unregister_framebuffer(info);
>> -if (ret < 0)
>> -DRM_DEBUG_KMS("failed unregister_framebuffer()\n");
>> -
>> -if (info->cmap.len)
>> -fb_dealloc_cmap(>cmap);
>> -
>> -framebuffer_release(info);
>> -}
>> +drm_fb_helper_unregister_fbi(fb_helper);
>> +drm_fb_helper_release_fbi(fb_helper);
>>
>> drm_fb_helper_fini(fb_helper);
>> }
>>
>
[PATCH 14/25] drm/exynos: Use new drm_fb_helper functions
On 2015ë
07ì 13ì¼ 15:38, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
>
> COMPILE TESTED ONLY.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 45
> +--
> 1 file changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index e0b085b..6975b70 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -65,9 +65,9 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
> static struct fb_ops exynos_drm_fb_ops = {
> .owner = THIS_MODULE,
> .fb_mmap= exynos_drm_fb_mmap,
> - .fb_fillrect= cfb_fillrect,
> - .fb_copyarea= cfb_copyarea,
> - .fb_imageblit = cfb_imageblit,
> + .fb_fillrect= drm_fb_helper_cfb_fillrect,
> + .fb_copyarea= drm_fb_helper_cfb_copyarea,
> + .fb_imageblit = drm_fb_helper_cfb_imageblit,
> .fb_check_var = drm_fb_helper_check_var,
> .fb_set_par = drm_fb_helper_set_par,
> .fb_blank = drm_fb_helper_blank,
> @@ -142,10 +142,10 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
>
> mutex_lock(>struct_mutex);
>
> - fbi = framebuffer_alloc(0, >dev);
> - if (!fbi) {
> + fbi = drm_fb_helper_alloc_fbi(helper);
> + if (IS_ERR(fbi)) {
> DRM_ERROR("failed to allocate fb info.\n");
> - ret = -ENOMEM;
> + ret = PTR_ERR(fbi);
> goto out;
> }
>
> @@ -165,7 +165,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
>
> if (IS_ERR(exynos_gem_obj)) {
> ret = PTR_ERR(exynos_gem_obj);
> - goto err_release_framebuffer;
> + goto err_release_fbi;
> }
>
> exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
> @@ -178,21 +178,13 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> goto err_destroy_gem;
> }
>
> - helper->fbdev = fbi;
> -
> fbi->par = helper;
> fbi->flags = FBINFO_FLAG_DEFAULT;
> fbi->fbops = _drm_fb_ops;
>
> - ret = fb_alloc_cmap(>cmap, 256, 0);
> - if (ret) {
> - DRM_ERROR("failed to allocate cmap.\n");
> - goto err_destroy_framebuffer;
> - }
> -
> ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
> if (ret < 0)
> - goto err_dealloc_cmap;
> + goto err_destroy_framebuffer;
With above change, err_dealloc_cmap label isn't used anymore so you need
to remove below lines,
err_dealloc_cmap:
fb_dealloc_cmap(>cmap);
Thanks,
Inki Dae
>
> mutex_unlock(>struct_mutex);
> return ret;
> @@ -203,8 +195,8 @@ err_destroy_framebuffer:
> drm_framebuffer_cleanup(helper->fb);
> err_destroy_gem:
> exynos_drm_gem_destroy(exynos_gem_obj);
> -err_release_framebuffer:
> - framebuffer_release(fbi);
> +err_release_fbi:
> + drm_fb_helper_release_fbi(helper);
>
> /*
> * if failed, all resources allocated above would be released by
> @@ -312,21 +304,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device
> *dev,
> }
> }
>
> - /* release linux framebuffer */
> - if (fb_helper->fbdev) {
> - struct fb_info *info;
> - int ret;
> -
> - info = fb_helper->fbdev;
> - ret = unregister_framebuffer(info);
> - if (ret < 0)
> - DRM_DEBUG_KMS("failed unregister_framebuffer()\n");
> -
> - if (info->cmap.len)
> - fb_dealloc_cmap(>cmap);
> -
> - framebuffer_release(info);
> - }
> + drm_fb_helper_unregister_fbi(fb_helper);
> + drm_fb_helper_release_fbi(fb_helper);
>
> drm_fb_helper_fini(fb_helper);
> }
>
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
Hi Daniel, On 2015ë 08ì 07ì¼ 21:28, Daniel Vetter wrote: > On Fri, Aug 7, 2015 at 1:50 PM, Inki Dae wrote: >> >> Booting is locked up here. This patch looks good to me so I tried to >> find why locked up and I found the booting is locked up as soon as >> console_lock function is called. Can you and other guys look into this >> issue? > > It's not locked up, you simply won't see any dmesg output after that. > Use Archit's Kconfig support in drm-misc to disable fbdev emulation > and try again. I didn't really look into this patch series. I will check it with this patch series next week and give Acked-by to you. Thanks, Inki Dae > -Daniel >
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
Hi Gustavo,
On 2015ë
08ì 06ì¼ 22:31, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> only a drm_encoder member and the internal exynos_drm_encoders ops that
> was directly mapped to the drm_encoder helper funcs.
>
> So now exynos DRM uses struct drm_encoder directly, this removes
> completely the struct exynos_drm_encoder.
>
Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch
is applied. Below is the booting logs,
[1.171318] console [ttySAC2] enabled
[1.175522] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 60,
base_baud = 0) is a S3C6400/10
[1.185545] [drm] Initialized drm 1.1.0 20060810
[1.194104] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.200352] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.207688] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.214313] [drm] No driver support for vblank timestamp query.
[1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0
Booting is locked up here. This patch looks good to me so I tried to
find why locked up and I found the booting is locked up as soon as
console_lock function is called. Can you and other guys look into this
issue?
Thanks,
Inki Dae
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/Makefile | 7 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
> drivers/gpu/drm/exynos/exynos_dp_core.c | 68 --
> drivers/gpu/drm/exynos/exynos_dp_core.h | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_core.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 51 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 47 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 80 +++--
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105
>
> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 22 --
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 71 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c| 85 +-
> 15 files changed, 236 insertions(+), 309 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h
>
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 7de0b10..61c2906 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -3,10 +3,9 @@
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
> -exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
> - exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
> - exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
> - exynos_drm_plane.o exynos_drm_dmabuf.o
> +exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fbdev.o \
> + exynos_drm_fb.o exynos_drm_buf.o exynos_drm_gem.o \
> + exynos_drm_core.o exynos_drm_plane.o exynos_drm_dmabuf.o
>
> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index e1a2ce7..0792654 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -61,7 +61,7 @@ struct decon_context {
> atomic_twait_vsync_event;
>
> struct exynos_drm_panel_info panel;
> - struct exynos_drm_encoder *encoder;
> + struct drm_encoder *encoder;
> };
>
> static const struct of_device_id decon_driver_dt_match[] = {
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4d49d25..92864ef 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -32,18 +32,18 @@
> #include
>
> #include "exynos_dp_core.h"
> -#include "exynos_drm_encoder.h"
> +#include "exynos_drm_crtc.h"
>
> #define ctx_from_connector(c)container_of(c, struct
> exynos_dp_device, \
> connector)
>
> static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
> {
> - return to_exynos_crtc(dp->encoder.base.crtc);
> + return to_exynos_crtc(dp->encoder.crtc)
[PATCH] drm/exynos/fimc: fix runtime pm support
On 2015ë 08ì 06ì¼ 19:13, Marek Szyprowski wrote: > Hello, > > On 2015-04-09 10:46, Marek Szyprowski wrote: >> Once pm_runtime_set_active() gets called, the kernel assumes that given >> device has already enabled runtime pm and will call pm_runtime_suspend() >> without matching pm_runtime_resume(). In case of DRM FIMC IPP driver, >> this will result in calling clk_disable() without respective call to >> clk_enable(). This patch removes call to pm_runtime_set_active() to >> ensure that pm_runtime_suspend/resume calls will match. >> >> Signed-off-by: Marek Szyprowski > > Gentle ping... Sorry, I missed it. Merged. Thanks, Inki Dae > >> --- >> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c >> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c >> index 842d6b8dc3c4..2a652359af64 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c >> @@ -1745,7 +1745,6 @@ static int fimc_probe(struct platform_device *pdev) >> spin_lock_init(>lock); >> platform_set_drvdata(pdev, ctx); >> -pm_runtime_set_active(dev); >> pm_runtime_enable(dev); >> ret = exynos_drm_ippdrv_register(ippdrv); > > Best regards
[PATCH v2 00/11] drm/exynos: remove exynos_drm_display and exynos_drm_encoder
On 2015ë
08ì 06ì¼ 08:24, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This patchset is another important step in the exynos clean up, it removes
> two exynos internal structs in favor of wider use of struct drm_encoder.
>
> Structs exynos_drm_display and exynos_drm_encoder were doing exactly what
> struct drm_encoder does so remove them makes the code cleaner, easier
> to understand and less error prone.
>
> Please review,
>
>Gustavo
>
> ---
> v2: - check ret value of hdmi_create_connector()
> - set dp->dpms_mode after enable/disable
I don't see patch v2 10/11 and 11/11 in my mailbox. Did you miss them?
Thanks,
Inki Dae
>
> Gustavo Padovan (11):
> drm/exynos: split display's .dpms() into .enable() and .disable()
> drm/exynos: remove wrappers for phy_power_{on,off}
> drm/exynos: remove unused .remove() and .check_mode() ops from display
> drm/exynos: simplify calculation of possible CRTCs
> drm/exynos: remove struct exynos_drm_display
> drm/exynos: remove extra call to hdmi_commit()
> drm/exynos: remove extra call to exynos_dp_commit()
> drm/exynos: remove exynos_encoder's .commit() op
> drm/exynos: remove exynos_drm_create_enc_conn()
> drm/exynos: fold encoder setup into exynos_drm_load()
> drm/exynos: remove struct exynos_drm_encoder layer
>
> drivers/gpu/drm/exynos/Makefile | 7 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 16 +--
> drivers/gpu/drm/exynos/exynos_dp_core.c | 119 ++-
> drivers/gpu/drm/exynos/exynos_dp_core.h | 3 +-
> drivers/gpu/drm/exynos/exynos_drm_core.c| 36 --
> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 3 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.h| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 96 ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 65 ++-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 130 ++---
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 174
>
> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 23
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 17 ++-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 90 --
> drivers/gpu/drm/exynos/exynos_hdmi.c| 160 -
> 16 files changed, 355 insertions(+), 599 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h
>
[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer
On 2015ë
08ì 04ì¼ 23:47, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-08-04 Inki Dae :
>
>> On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
>>> only a drm_encoder member and the internal exynos_drm_encoders ops that
>>> was directly mapped to the drm_encoder helper funcs.
>>>
>>> So now exynos DRM uses struct drm_encoder directly, this removes
>>> completely the struct exynos_drm_encoder.
>>>
>>> Signed-off-by: Gustavo Padovan
>>> ---
>>> drivers/gpu/drm/exynos/Makefile | 7 +-
>>> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_dp_core.c | 68 --
>>> drivers/gpu/drm/exynos/exynos_dp_core.h | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_core.c| 1 -
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 1 -
>>> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 51 --
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 47 ++---
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 80 +++--
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 22 --
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 71 ++-
>>> drivers/gpu/drm/exynos/exynos_hdmi.c| 85 +-
>>> 15 files changed, 236 insertions(+), 309 deletions(-)
>>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
>>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h
>>
>> [-- SNIP --]
>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index d791ad4..a87d030 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -30,7 +30,6 @@
>>> #include
>>>
>>> #include "exynos_drm_crtc.h"
>>> -#include "exynos_drm_encoder.h"
>>> #include "exynos_drm_drv.h"
>>>
>>> /* returns true iff both arguments logically differs */
>>> @@ -260,7 +259,7 @@ struct exynos_dsi_driver_data {
>>> };
>>>
>>> struct exynos_dsi {
>>> - struct exynos_drm_encoder encoder;
>>> + struct drm_encoder encoder;
>>> struct mipi_dsi_host dsi_host;
>>> struct drm_connector connector;
>>> struct device_node *panel_node;
>>> @@ -296,7 +295,7 @@ struct exynos_dsi {
>>> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>>> #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>>>
>>> -static inline struct exynos_dsi *encoder_to_dsi(struct exynos_drm_encoder
>>> *e)
>>> +static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
>>> {
>>> return container_of(e, struct exynos_dsi, encoder);
>>> }
>>> @@ -1273,7 +1272,7 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>>> *dev_id)
>>> static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
>>> {
>>> struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
>>> - struct drm_encoder *encoder = >encoder.base;
>>> + struct drm_encoder *encoder = >encoder;
>>>
>>> if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
>>> exynos_drm_crtc_te_handler(encoder->crtc);
>>> @@ -1519,7 +1518,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi
>>> *dsi)
>>> dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
>>> }
>>>
>>> -static void exynos_dsi_enable(struct exynos_drm_encoder *encoder)
>>> +static void exynos_dsi_enable(struct drm_encoder *encoder)
>>> {
>>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>>> int ret;
>>> @@ -1555,7 +1554,7 @@ static void exynos_dsi_enable(struct
>>> exynos_drm_encoder *encoder)
>>> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
>>> }
>>>
>>> -static void exynos_dsi_disable(struct exynos_drm_encoder *encoder)
>>> +static void exynos_dsi_disable(struct drm_encoder
[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> only a drm_encoder member and the internal exynos_drm_encoders ops that
> was directly mapped to the drm_encoder helper funcs.
>
> So now exynos DRM uses struct drm_encoder directly, this removes
> completely the struct exynos_drm_encoder.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/Makefile | 7 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
> drivers/gpu/drm/exynos/exynos_dp_core.c | 68 --
> drivers/gpu/drm/exynos/exynos_dp_core.h | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_core.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 51 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 47 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 80 +++--
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105
>
> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 22 --
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 71 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c| 85 +-
> 15 files changed, 236 insertions(+), 309 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h
[-- SNIP --]
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index d791ad4..a87d030 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -30,7 +30,6 @@
> #include
>
> #include "exynos_drm_crtc.h"
> -#include "exynos_drm_encoder.h"
> #include "exynos_drm_drv.h"
>
> /* returns true iff both arguments logically differs */
> @@ -260,7 +259,7 @@ struct exynos_dsi_driver_data {
> };
>
> struct exynos_dsi {
> - struct exynos_drm_encoder encoder;
> + struct drm_encoder encoder;
> struct mipi_dsi_host dsi_host;
> struct drm_connector connector;
> struct device_node *panel_node;
> @@ -296,7 +295,7 @@ struct exynos_dsi {
> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
> #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>
> -static inline struct exynos_dsi *encoder_to_dsi(struct exynos_drm_encoder *e)
> +static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
> {
> return container_of(e, struct exynos_dsi, encoder);
> }
> @@ -1273,7 +1272,7 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
> static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
> {
> struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
> - struct drm_encoder *encoder = >encoder.base;
> + struct drm_encoder *encoder = >encoder;
>
> if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
> exynos_drm_crtc_te_handler(encoder->crtc);
> @@ -1519,7 +1518,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
> dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
> }
>
> -static void exynos_dsi_enable(struct exynos_drm_encoder *encoder)
> +static void exynos_dsi_enable(struct drm_encoder *encoder)
> {
> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> int ret;
> @@ -1555,7 +1554,7 @@ static void exynos_dsi_enable(struct exynos_drm_encoder
> *encoder)
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> }
>
> -static void exynos_dsi_disable(struct exynos_drm_encoder *encoder)
> +static void exynos_dsi_disable(struct drm_encoder *encoder)
> {
> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>
> @@ -1583,7 +1582,7 @@ exynos_dsi_detect(struct drm_connector *connector, bool
> force)
> if (dsi->panel)
> drm_panel_attach(dsi->panel, >connector);
> } else if (!dsi->panel_node) {
> - struct exynos_drm_encoder *encoder;
> + struct drm_encoder *encoder;
>
> encoder = platform_get_drvdata(to_platform_device(dsi->dev));
> exynos_dsi_disable(encoder);
> @@ -1629,7 +1628,7 @@ exynos_dsi_best_encoder(struct drm_connector *connector)
> {
> struct exynos_dsi *dsi = connector_to_dsi(connector);
>
> - return >encoder.base;
> + return >encoder;
> }
>
> static struct drm_connector_helper_funcs exynos_dsi_connector_helper_funcs =
> {
> @@ -1637,11 +1636,9 @@ static struct drm_connector_helper_funcs
> exynos_dsi_connector_helper_funcs = {
> .best_encoder = exynos_dsi_best_encoder,
> };
>
> -static int exynos_dsi_create_connector(
> - struct exynos_drm_encoder *exynos_encoder)
> +static int exynos_dsi_create_connector(struct
[PATCH 09/11] drm/exynos: remove exynos_drm_create_enc_conn()
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This functions was just hiding the encoder and connector creation in
> a way that was less clean than if we get rid of it. For example,
> exynos_encoder ops had .create_connector() defined only because we were
> handing off the encoder and connector creation to
> exynos_drm_create_enc_conn(). Without this function we can directly call
> the create_connector function internally in the code, without the need of
> any vtable access.
>
> It also does some refactoring in the code like creating a bind function
> for dpi devices.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 +--
> drivers/gpu/drm/exynos/exynos_dp_core.c | 20 ---
> drivers/gpu/drm/exynos/exynos_drm_core.c| 30
> -
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 26 +++--
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 12 ++--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 ---
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 11 +++
> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 4 +++-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 3 +--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 20 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c| 21 +---
> 11 files changed, 101 insertions(+), 69 deletions(-)
>
[-- SNIP --]
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 11bac50..f72ceeb 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -44,6 +44,7 @@
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_crtc.h"
> +#include "exynos_drm_encoder.h"
> #include "exynos_mixer.h"
>
> #include
> @@ -1783,7 +1784,6 @@ static void hdmi_disable(struct exynos_drm_encoder
> *encoder)
> }
>
> static struct exynos_drm_encoder_ops hdmi_encoder_ops = {
> - .create_connector = hdmi_create_connector,
> .mode_fixup = hdmi_mode_fixup,
> .mode_set = hdmi_mode_set,
> .enable = hdmi_enable,
> @@ -1917,11 +1917,26 @@ static int hdmi_bind(struct device *dev, struct
> device *master, void *data)
> {
> struct drm_device *drm_dev = data;
> struct hdmi_context *hdata = dev_get_drvdata(dev);
> + struct exynos_drm_encoder *exynos_encoder = >encoder;
> + int ret;
>
> hdata->drm_dev = drm_dev;
>
> - return exynos_drm_create_enc_conn(drm_dev, >encoder,
> - EXYNOS_DISPLAY_TYPE_HDMI);
> + ret = exynos_drm_encoder_create(drm_dev, exynos_encoder,
> + EXYNOS_DISPLAY_TYPE_HDMI);
> + if (ret) {
> + DRM_ERROR("failed to create encoder\n");
> + return ret;
> + }
> +
> + hdmi_create_connector(exynos_encoder);
ret = hdmi_create_connector(exynos_encoder);
> + if (ret) {
> + DRM_ERROR("failed to create connector ret = %d\n", ret);
> + drm_encoder_cleanup(_encoder->base);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static void hdmi_unbind(struct device *dev, struct device *master, void
> *data)
>
[PATCH v2] drm/exynos: clear channels only when iommu is enabled
On 2015ë 07ì 31ì¼ 09:32, Krzysztof Kozlowski wrote: > On 28.07.2015 17:51, Joonyoung Shim wrote: >> This is simplest solution about reported problem[1]. It's no problem to >> clear channel only when iommu is enabled, if we consider that we cannot >> recognize iommu errors when iommu is disabled and it have been valid >> until now. But this cannot be nice solution. >> >> [1] https://lkml.org/lkml/2015/7/21/404 >> >> Reported-by: Krzysztof Kozlowski >> Signed-off-by: Joonyoung Shim > > I tested this patch on my Odroid XU3-Lite with hardkernel u-boot and it > fixes the booting hang. Thanks! Thanks for the test. This patch fixes the booting hang issue but I'm not sure of this patch being able to resolve the issue clearly. In relation to this, I tried to resolve the issue using sub driver stuff, which makes a probe callback for fimd sub driver to be called after crtc and connector binding is completed. I guessed that with this, ACLK_200_DISP1 would be enabled by connector driver - mipi dsi or panel driver. However, the moment that the clock is enabled is at mode setting operation so the patch doesn't resolve the issue because the callback I added will be called before mode setting operation. So the solution we could try would be to make FIMD driver to enable relevant clock in case of Exynos5422 SoC. However, this way is also not clear to me because it is required for additional device tree binding. Anyway, I merged below patch so let's resolve this issue with more generic way later. P.s., I removed the patch which incurred the kernel hang issue from exynos-drm-fixes, and moved it to exynos-drm-next with below patch so now there must be no any problem with exynos-drm-fixes. Thanks, Inki Dae > > The test was not thorough - only booting and without any display output > (HDMI). > > Best regards, > Krzysztof > > >> --- >> v2: add Reported-by. >> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c >> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c >> index 8d362b9..337af02 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c >> @@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device >> *master, void *data) >> if (ctx->display) >> exynos_drm_create_enc_conn(drm_dev, ctx->display); >> >> -fimd_clear_channels(ctx->crtc); >> +if (is_drm_iommu_supported(drm_dev)) >> +fimd_clear_channels(ctx->crtc); >> >> ret = drm_iommu_attach_device(drm_dev, dev); >> if (ret) >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH v3 1/9] drm/exynos: pass the correct pipe number
Hi Gustavo,
For 1 through 9 merged. And I guess you have the rest we have to review
but this patch series doesn't have consistency of previous, v2.
So please, post the rest again re-basing on top of exynos-drm-next.
Thanks,
Inki Dae
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
> Hi Inki,
>
> Any comments about this series?
>
> Thanks,
>
> Gustavo
>
> 2015-07-16 Gustavo Padovan :
>
>> From: Gustavo Padovan
>>
>> Instead of giving -1 to as arg to drm_send_vblank_event() pass the
>> correct pipe number to it.
>>
>> Signed-off-by: Gustavo Padovan
>> Reviewed-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 644b4b7..22b9ca0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
>> *dev, int pipe)
>> spin_lock_irqsave(>event_lock, flags);
>> if (exynos_crtc->event) {
>>
>> -drm_send_vblank_event(dev, -1, exynos_crtc->event);
>> +drm_send_vblank_event(dev, pipe, exynos_crtc->event);
>> drm_vblank_put(dev, pipe);
>> wake_up(_crtc->pending_flip_queue);
>>
>> --
>> 2.1.0
>>
>
[PATCH v3 1/9] drm/exynos: pass the correct pipe number
Hi Gustavo,
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
> Hi Inki,
>
> Any comments about this series?
Will review all of them. Now we are reviewing fix-up and clean-up patches.
Thanks,
Inki Dae
>
> Thanks,
>
> Gustavo
>
> 2015-07-16 Gustavo Padovan :
>
>> From: Gustavo Padovan
>>
>> Instead of giving -1 to as arg to drm_send_vblank_event() pass the
>> correct pipe number to it.
>>
>> Signed-off-by: Gustavo Padovan
>> Reviewed-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 644b4b7..22b9ca0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
>> *dev, int pipe)
>> spin_lock_irqsave(>event_lock, flags);
>> if (exynos_crtc->event) {
>>
>> -drm_send_vblank_event(dev, -1, exynos_crtc->event);
>> +drm_send_vblank_event(dev, pipe, exynos_crtc->event);
>> drm_vblank_put(dev, pipe);
>> wake_up(_crtc->pending_flip_queue);
>>
>> --
>> 2.1.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH v2] drm/exynos: clear channels only when iommu is enabled
+ samsung-soc On 2015ë 07ì 28ì¼ 17:51, Joonyoung Shim wrote: > This is simplest solution about reported problem[1]. It's no problem to > clear channel only when iommu is enabled, if we consider that we cannot > recognize iommu errors when iommu is disabled and it have been valid > until now. But this cannot be nice solution. > > [1] https://lkml.org/lkml/2015/7/21/404 > > Reported-by: Krzysztof Kozlowski > Signed-off-by: Joonyoung Shim > --- > v2: add Reported-by. > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index 8d362b9..337af02 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device > *master, void *data) > if (ctx->display) > exynos_drm_create_enc_conn(drm_dev, ctx->display); > > - fimd_clear_channels(ctx->crtc); > + if (is_drm_iommu_supported(drm_dev)) > + fimd_clear_channels(ctx->crtc); > > ret = drm_iommu_attach_device(drm_dev, dev); > if (ret) >
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015ë 07ì 22ì¼ 19:08, Inki Dae wrote: > On 2015ë 07ì 22ì¼ 17:42, Joonyoung Shim wrote: >> On 07/22/2015 05:22 PM, Inki Dae wrote: >>> On 2015ë 07ì 22ì¼ 17:12, Joonyoung Shim wrote: >>>> On 07/22/2015 01:55 PM, Inki Dae wrote: >>>>> On 2015ë 07ì 22ì¼ 11:02, Joonyoung Shim wrote: >>>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos >>>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >>>>>>> >>>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >>>>>>> commit d80167b85024982c5f18d0481a5c248100360118 >>>>>>> Author: Joonyoung Shim >>>>>>> Date: Thu Jul 2 21:49:39 2015 +0900 >>>>>>> >>>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible >>>>>>> >>>>>>> Already drm_iommu_attach_device checks whether support iommu >>>>>>> internally. >>>>>>> It should clear channels always regardless iommu support. We didn't >>>>>>> know >>>>>>> because we can detect the problem when iommu is enabled, so we don't >>>>>>> have to use drm_iommu_attach_device_if_possible and then we can >>>>>>> remove >>>>>>> drm_iommu_attach_device_if_possible and clear_channels function >>>>>>> pointer. >>>>>>> >>>>>>> Signed-off-by: Joonyoung Shim >>>>>>> Tested-by: Marek Szyprowski >>>>>>> Signed-off-by: Inki Dae >>>>>>> >>>>>>> :04 04 83379efbf4960f58d680371628ec04387935bd53 >>>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >>>>>>> >>>>>>> >>>>>>> Config: exynos >>>>>>> Boot log from Odroid XU3-Lite attached. >>>>>>> >>>>>>> Any hints or ideas? >>>>>> >>>>>> The point that hangs is when accesses fimd register in >>>>>> fimd_clear_channels function, so i doubt clock setting for fimd. >>>>>> >>>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1 >>>>>> clock. >>>>>> >>>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it >>>>>> support. Any ideas? >>>>> >>>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also >>>>> device driver should enable all relevant clocks before the device >>>>> accesses its own registers. >>>>> >>>>> Best way would be that the clock is enabled by common clock framework >>>>> but it seems there is no anything that the clock framework can do it. So >>>>> I think what we have to do is to add the clock support to device tree. >>>> >>>> It's not easy problem to me. Should we add which clock? I think we >>>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below >>>> hierarchy, right? Then we should control gate clocks, but we have not >>>> controlled any gate clocks using BTS_ prefix. >>>> >>>> The clock hierarchy from Exynos5422 user manual, >>>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK >>>>HDMI PHY >>>>MIC1 >>>>DSIM1 >>>>DPTX LINK >>>>MDNIE1 >>>>SYSMMU_MIXER >>>>SYSMMU_FIMD1_M0 >>>>SYSMMU_FIMD1_M1 >>>>BTS_TVM0 >>>>BTS_TVM1 >>>>BTS_FIMD1_M0 >>>>BTS_FIMD1_M1 >>>> >>>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock, >>>> just it should be controlled by connector drivers, e.g. dsi, dp because >>
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015ë 07ì 22ì¼ 17:42, Joonyoung Shim wrote: > On 07/22/2015 05:22 PM, Inki Dae wrote: >> On 2015ë 07ì 22ì¼ 17:12, Joonyoung Shim wrote: >>> On 07/22/2015 01:55 PM, Inki Dae wrote: >>>> On 2015ë 07ì 22ì¼ 11:02, Joonyoung Shim wrote: >>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >>>>>> Hi, >>>>>> >>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos >>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >>>>>> >>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >>>>>> commit d80167b85024982c5f18d0481a5c248100360118 >>>>>> Author: Joonyoung Shim >>>>>> Date: Thu Jul 2 21:49:39 2015 +0900 >>>>>> >>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible >>>>>> >>>>>> Already drm_iommu_attach_device checks whether support iommu >>>>>> internally. >>>>>> It should clear channels always regardless iommu support. We didn't >>>>>> know >>>>>> because we can detect the problem when iommu is enabled, so we don't >>>>>> have to use drm_iommu_attach_device_if_possible and then we can >>>>>> remove >>>>>> drm_iommu_attach_device_if_possible and clear_channels function >>>>>> pointer. >>>>>> >>>>>> Signed-off-by: Joonyoung Shim >>>>>> Tested-by: Marek Szyprowski >>>>>> Signed-off-by: Inki Dae >>>>>> >>>>>> :04 04 83379efbf4960f58d680371628ec04387935bd53 >>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >>>>>> >>>>>> >>>>>> Config: exynos >>>>>> Boot log from Odroid XU3-Lite attached. >>>>>> >>>>>> Any hints or ideas? >>>>> >>>>> The point that hangs is when accesses fimd register in >>>>> fimd_clear_channels function, so i doubt clock setting for fimd. >>>>> >>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1 >>>>> clock. >>>>> >>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it >>>>> support. Any ideas? >>>> >>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also >>>> device driver should enable all relevant clocks before the device >>>> accesses its own registers. >>>> >>>> Best way would be that the clock is enabled by common clock framework >>>> but it seems there is no anything that the clock framework can do it. So >>>> I think what we have to do is to add the clock support to device tree. >>> >>> It's not easy problem to me. Should we add which clock? I think we >>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below >>> hierarchy, right? Then we should control gate clocks, but we have not >>> controlled any gate clocks using BTS_ prefix. >>> >>> The clock hierarchy from Exynos5422 user manual, >>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK >>>HDMI PHY >>>MIC1 >>>DSIM1 >>>DPTX LINK >>>MDNIE1 >>>SYSMMU_MIXER >>>SYSMMU_FIMD1_M0 >>>SYSMMU_FIMD1_M1 >>>BTS_TVM0 >>>BTS_TVM1 >>>BTS_FIMD1_M0 >>>BTS_FIMD1_M1 >>> >>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock, >>> just it should be controlled by connector drivers, e.g. dsi, dp because >>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure >>> about this, just i thought that Exynos5 SoCs don't have any gpios for >>> dpi, so they cannot use dpi, right?). >>> >>> It needs to probe connector driver like dsi or dp earlier than fimd and >>> fimd_bind function should return error if connector driver like dsi or >>> dp was not probed. This is also not easy to me. >> >> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1 >> should be enabled. So I guess the problem would be due to below line of >> clk-exynos5420.c, >> >> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0), >> >> Can you check it again after modifying it like below?, >> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0), > > No, parent clock of fimd1 gate clock is ACLK_300_DISP1. Yes, I checked just it through exynos5420 and exynos5422 document. I just guessed. So do you mean that aclk200_disp1 affects FIMD controller even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very strange. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015ë 07ì 22ì¼ 17:12, Joonyoung Shim wrote: > On 07/22/2015 01:55 PM, Inki Dae wrote: >> On 2015ë 07ì 22ì¼ 11:02, Joonyoung Shim wrote: >>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >>>> Hi, >>>> >>>> Today's linux-next (next-20150721) encounters boot failures on Exynos >>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >>>> >>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >>>> commit d80167b85024982c5f18d0481a5c248100360118 >>>> Author: Joonyoung Shim >>>> Date: Thu Jul 2 21:49:39 2015 +0900 >>>> >>>> drm/exynos: remove drm_iommu_attach_device_if_possible >>>> >>>> Already drm_iommu_attach_device checks whether support iommu >>>> internally. >>>> It should clear channels always regardless iommu support. We didn't >>>> know >>>> because we can detect the problem when iommu is enabled, so we don't >>>> have to use drm_iommu_attach_device_if_possible and then we can remove >>>> drm_iommu_attach_device_if_possible and clear_channels function >>>> pointer. >>>> >>>> Signed-off-by: Joonyoung Shim >>>> Tested-by: Marek Szyprowski >>>> Signed-off-by: Inki Dae >>>> >>>> :04 04 83379efbf4960f58d680371628ec04387935bd53 >>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >>>> >>>> >>>> Config: exynos >>>> Boot log from Odroid XU3-Lite attached. >>>> >>>> Any hints or ideas? >>> >>> The point that hangs is when accesses fimd register in >>> fimd_clear_channels function, so i doubt clock setting for fimd. >>> >>> It's gone something that hangs after i enable gating for ACLK_200_DISP1 >>> clock. >>> >>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it >>> support. Any ideas? >> >> I think bootloader should have enabled ACLK_200_DISP1 clock and also >> device driver should enable all relevant clocks before the device >> accesses its own registers. >> >> Best way would be that the clock is enabled by common clock framework >> but it seems there is no anything that the clock framework can do it. So >> I think what we have to do is to add the clock support to device tree. > > It's not easy problem to me. Should we add which clock? I think we > cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below > hierarchy, right? Then we should control gate clocks, but we have not > controlled any gate clocks using BTS_ prefix. > > The clock hierarchy from Exynos5422 user manual, > ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK >HDMI PHY >MIC1 >DSIM1 >DPTX LINK >MDNIE1 >SYSMMU_MIXER >SYSMMU_FIMD1_M0 >SYSMMU_FIMD1_M1 >BTS_TVM0 >BTS_TVM1 >BTS_FIMD1_M0 >BTS_FIMD1_M1 > > Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock, > just it should be controlled by connector drivers, e.g. dsi, dp because > fimd only cannot operate, so dsi or dp must need (Actually i'm not sure > about this, just i thought that Exynos5 SoCs don't have any gpios for > dpi, so they cannot use dpi, right?). > > It needs to probe connector driver like dsi or dp earlier than fimd and > fimd_bind function should return error if connector driver like dsi or > dp was not probed. This is also not easy to me. In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1 should be enabled. So I guess the problem would be due to below line of clk-exynos5420.c, GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0), Can you check it again after modifying it like below?, GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0), Thanks, Inki Dae > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015ë 07ì 22ì¼ 11:02, Joonyoung Shim wrote: > On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >> Hi, >> >> Today's linux-next (next-20150721) encounters boot failures on Exynos >> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >> >> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >> commit d80167b85024982c5f18d0481a5c248100360118 >> Author: Joonyoung Shim >> Date: Thu Jul 2 21:49:39 2015 +0900 >> >> drm/exynos: remove drm_iommu_attach_device_if_possible >> >> Already drm_iommu_attach_device checks whether support iommu internally. >> It should clear channels always regardless iommu support. We didn't know >> because we can detect the problem when iommu is enabled, so we don't >> have to use drm_iommu_attach_device_if_possible and then we can remove >> drm_iommu_attach_device_if_possible and clear_channels function pointer. >> >> Signed-off-by: Joonyoung Shim >> Tested-by: Marek Szyprowski >> Signed-off-by: Inki Dae >> >> :04 04 83379efbf4960f58d680371628ec04387935bd53 >> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >> >> >> Config: exynos >> Boot log from Odroid XU3-Lite attached. >> >> Any hints or ideas? > > The point that hangs is when accesses fimd register in > fimd_clear_channels function, so i doubt clock setting for fimd. > > It's gone something that hangs after i enable gating for ACLK_200_DISP1 > clock. > > If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it > support. Any ideas? I think bootloader should have enabled ACLK_200_DISP1 clock and also device driver should enable all relevant clocks before the device accesses its own registers. Best way would be that the clock is enabled by common clock framework but it seems there is no anything that the clock framework can do it. So I think what we have to do is to add the clock support to device tree. Other idea? Thanks, Inki Dae > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function
Hi Stephen, On 2015ë 06ì 23ì¼ 15:43, Stephen Rothwell wrote: > Hi Inki, > > On Tue, 23 Jun 2015 15:14:53 +0900 Inki Dae wrote: >> >> This patch fixes the below build error reported by Stephen, >> https://lkml.org/lkml/2015/6/22/665 > > Don't do this. Put the errors explicitly in the mail. lkml.org URLs > are particularly bad. Posted it again. Thanks, Inki Dae >
[PATCH Resend] of: fix a build error to f_graph_get_endpoint_by_regs function
This patch fixes the below build error reported by Stephen,
Stephen reported:
After merging the drm-exynos tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
adv7604.c:(.text+0x586c): multiple definition of
`of_graph_get_endpoint_by_regs'
drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
drivers/media/platform/soc_camera/atmel-isi.o: In function
`of_graph_get_endpoint_by_regs':
atmel-isi.c:(.text+0x1ec9): multiple definition of
`of_graph_get_endpoint_by_regs'
drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3):
first defined here
drivers/media/platform/soc_camera/rcar_vin.o: In function
`of_graph_get_endpoint_by_regs':
rcar_vin.c:(.text+0x307c): multiple definition of
`of_graph_get_endpoint_by_regs'
drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3):
first defined here
Caused by commit:
a0f7001c18ca ("of: add helper for getting endpoint node of specific
identifiers")
To fix the error, this patch declares of_graph_get_endpoint_by_regs function
with "static inline".
Signed-off-by: Inki Dae
---
include/linux/of_graph.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 1c1d5b9..f8bcd0e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -71,7 +71,7 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
}
-struct device_node *of_graph_get_endpoint_by_regs(
+static inline struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg)
{
return NULL;
--
1.7.9.5
[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function
This patch fixes the below build error reported by Stephen,
https://lkml.org/lkml/2015/6/22/665
To fix the error, this patch declares of_graph_get_endpoint_by_regs function
with "static inline".
Signed-off-by: Inki Dae
---
include/linux/of_graph.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 1c1d5b9..f8bcd0e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -71,7 +71,7 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
}
-struct device_node *of_graph_get_endpoint_by_regs(
+static inline struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg)
{
return NULL;
--
1.7.9.5
[PATCH v6 06/15] of: add helper for getting endpoint node of specific identifiers
On 2015ë
06ì 23ì¼ 09:19, Dave Airlie wrote:
> On 12 June 2015 at 22:59, Hyungwon Hwang wrote:
>> When there are multiple ports or multiple endpoints in a port, they have to
>> be
>> distinguished by the value of reg property. It is common. The drivers can get
>> the specific endpoint in the specific port via this function. Now the drivers
>> have to implement this code in themselves or have to force the order of dt
>> nodes
>> to get the right node.
>>
>> Signed-off-by: Hyungwon Hwang
>> Acked-by: Rob Herring <robh+dt at kernel.org>
>
> FYI, Since I'm merging this via exynos-next into my tree, it broke
> module builds of exynos, because it doesn't export the symbol it adds,
> I've added a patch to my -next tree to fix it up.
>
> Inki, in future can you add a modular build to pre-pull testing.
Yes I do. I should have tested the modular build. Sorry for this.
Thanks,
Inki Dae
>
> Dave.
>
>> ---
>> Changes before:
>> - Refer https://patchwork.kernel.org/patch/6191751/
>> Changes for v6:
>> - None
>> drivers/of/base.c| 33 +
>> include/linux/of_graph.h | 8
>> 2 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 99764db..f3b583b 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -2233,6 +2233,39 @@ struct device_node *of_graph_get_next_endpoint(const
>> struct device_node *parent,
>> EXPORT_SYMBOL(of_graph_get_next_endpoint);
>>
>> /**
>> + * of_graph_get_endpoint_by_regs() - get endpoint node of specific
>> identifiers
>> + * @parent: pointer to the parent device node
>> + * @port_reg: identifier (value of reg property) of the parent port node
>> + * @reg: identifier (value of reg property) of the endpoint node
>> + *
>> + * Return: An 'endpoint' node pointer which is identified by reg and at the
>> same
>> + * is the child of a port node identified by port_reg. reg and port_reg are
>> + * ignored when they are -1.
>> + */
>> +struct device_node *of_graph_get_endpoint_by_regs(
>> + const struct device_node *parent, int port_reg, int reg)
>> +{
>> + struct of_endpoint endpoint;
>> + struct device_node *node, *prev_node = NULL;
>> +
>> + while (1) {
>> + node = of_graph_get_next_endpoint(parent, prev_node);
>> + of_node_put(prev_node);
>> + if (!node)
>> + break;
>> +
>> + of_graph_parse_endpoint(node, );
>> + if (((port_reg == -1) || (endpoint.port == port_reg)) &&
>> + ((reg == -1) || (endpoint.id == reg)))
>> + return node;
>> +
>> + prev_node = node;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +/**
>> * of_graph_get_remote_port_parent() - get remote port's parent node
>> * @node: pointer to a local endpoint device_node
>> *
>> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
>> index 7bc92e0..1c1d5b9 100644
>> --- a/include/linux/of_graph.h
>> +++ b/include/linux/of_graph.h
>> @@ -45,6 +45,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
>> struct device_node *of_graph_get_port_by_id(struct device_node *node, u32
>> id);
>> struct device_node *of_graph_get_next_endpoint(const struct device_node
>> *parent,
>> struct device_node *previous);
>> +struct device_node *of_graph_get_endpoint_by_regs(
>> + const struct device_node *parent, int port_reg, int reg);
>> struct device_node *of_graph_get_remote_port_parent(
>> const struct device_node *node);
>> struct device_node *of_graph_get_remote_port(const struct device_node
>> *node);
>> @@ -69,6 +71,12 @@ static inline struct device_node
>> *of_graph_get_next_endpoint(
>> return NULL;
>> }
>>
>> +struct device_node *of_graph_get_endpoint_by_regs(
>> + const struct device_node *parent, int port_reg, int reg)
>> +{
>> + return NULL;
>> +}
>> +
>> static inline struct device_node *of_graph_get_remote_port_parent(
>> const struct device_node *node)
>> {
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>
[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'
On 2015ë 06ì 23ì¼ 11:10, Krzysztof Kozlowski wrote: > 2015-06-22 21:35 GMT+09:00 Krzysztof Kozlowski : >> 2015-06-22 20:42 GMT+09:00 Inki Dae : >>> + Krzysztof >>> >>> On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote: >>>> On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote: >>>>> The clock which was named as 'pll_clk' is actually not the clock source >>>>> of PLL in MIPI DSI. This patch fixes this disagreement. >>>> >>>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd >>>> like to merge this patch to mainline through drm-next. >> >> Thanks for forwarding me other necessary patch. All that burden could >> be easily avoided by sending everything to samsung-soc anyway. >> >> The patch itself looks good: >> Acked-by: Krzysztof Kozlowski >> >> Best regards, >> Krzysztof > > To clarify. There were seven versions of this patch and none of them > were sent to samsung-soc list, to Kukjin Kim or to me. > > I also wonder about patch 2: "of: add helper for getting endpoint node > with specific identifiers" > for which I can't find respective ack from Rob Herring (+Cc). I only found > this: > http://www.spinics.net/lists/devicetree/msg69336.html > but there are only comments, not an ack. Below is the comments from Rob Herring. How about subscribing device tree mainling list? You are a maintainer of Exynos SoC. This patch was posted to device tree mailing list ccing Grant and Rob. If you listen to only Samsung SoC mailing list then you couldn't find this patch in your email box. "On Sun, Feb 22, 2015 at 7:41 PM, Hyungwon Hwang wrote: > When there are multiple ports or multiple endpoints in a port, they have to be > distinguished by the value of reg property. It is common. The drivers can get > the specific endpoint in the specific port via this function. Now the drivers > have to implement this code in themselves or have to force the order of dt nodes > to get the right node. > > Signed-off-by: Hyungwon Hwang Acked-by: Rob Herring I'm not applying as there is no user, so apply this patch along with a user of the function." That is why I merged this patch to exynos-drm-next. Thanks, Inki Dae > > Best regards, > Krzysztof > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in >
[PATCH v6 08/15] drm/exynos: dsi: rename pll_clk to sclk_clk
+ Samsung SoC mailing list.
On 2015ë
06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly. But for the backward
> compatibility, the old clock name "pll_clk" is also OK.
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes before:
> - Refer https://patchwork.kernel.org/patch/6191721
> Changes for v6:
> - Merged 2 patches
>drm/exynos: dsi: add the backward compatibility for the renamed clock
>drm/exynos: dsi: rename pll_clk to sclk_clk
>
> .../devicetree/bindings/video/exynos_dsim.txt | 7 +++--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c| 36
> ++
> 2 files changed, 20 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
> b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> index 802aa7e..44659dd 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> @@ -10,13 +10,14 @@ Required properties:
>- interrupts: should contain DSI interrupt
>- clocks: list of clock specifiers, must contain an entry for each required
> entry in clock-names
> - - clock-names: should include "bus_clk"and "pll_clk" entries
> + - clock-names: should include "bus_clk"and "sclk_mipi" entries
> + the use of "pll_clk" is deprecated
>- phys: list of phy specifiers, must contain an entry for each required
> entry in phy-names
>- phy-names: should include "dsim" entry
>- vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
>- vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
> - - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
> + - samsung,pll-clock-frequency: specifies frequency of the oscillator clock
>- #address-cells, #size-cells: should be set respectively to <1> and <0>
> according to DSI host bindings (see MIPI DSI bindings [1])
>
> @@ -48,7 +49,7 @@ Example:
> reg = <0x11C8 0x1>;
> interrupts = <0 79 0>;
> clocks = < 286>, < 143>;
> - clock-names = "bus_clk", "pll_clk";
> + clock-names = "bus_clk", "sclk_mipi";
> phys = <_phy 1>;
> phy-names = "dsim";
> vddcore-supply = <_reg>;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index c1999ad..a3bfac2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -235,6 +235,8 @@
> #define DSI_XFER_TIMEOUT_MS 100
> #define DSI_RX_FIFO_EMPTY0x3082
>
> +#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
> +
> enum exynos_dsi_transfer_type {
> EXYNOS_DSI_TX,
> EXYNOS_DSI_RX,
> @@ -279,7 +281,7 @@ struct exynos_dsi {
>
> void __iomem *reg_base;
> struct phy *phy;
> - struct clk *pll_clk;
> + struct clk *sclk_clk;
> struct clk *bus_clk;
> struct regulator_bulk_data supplies[2];
> int irq;
> @@ -433,16 +435,7 @@ static unsigned long exynos_dsi_set_pll(struct
> exynos_dsi *dsi,
> u16 m;
> u32 reg;
>
> - clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
> -
> - fin = clk_get_rate(dsi->pll_clk);
> - if (!fin) {
> - dev_err(dsi->dev, "failed to get PLL clock frequency\n");
> - return 0;
> - }
> -
> - dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
> -
> + fin = dsi->pll_clk_rate;
> fout = exynos_dsi_pll_find_pms(dsi, fin, freq, , , );
> if (!fout) {
> dev_err(dsi->dev,
> @@ -1313,10 +1306,10 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
> goto err_bus_clk;
> }
>
> - ret = clk_prepare_enable(dsi->pll_clk);
> + ret = clk_prepare_enable(dsi->sclk_clk);
> if (ret < 0) {
> dev_err(dsi->dev, "cannot enable pll clock %d\n", ret);
> - goto err_pll_clk;
> + goto err_sclk_clk;
> }
>
> ret = phy_power_on(dsi->phy);
> @@ -1328,8 +1321,8 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
> return 0;
>
> err_phy:
> - clk_disable_unprepare(dsi->pll_clk);
> -err_pll_clk:
> + clk_disable_unprepare(dsi->sclk_clk);
> +err_sclk_clk:
> clk_disable_unprepare(dsi->bus_clk);
> err_bus_clk:
> regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1355,7 +1348,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
>
> phy_power_off(dsi->phy);
>
> - clk_disable_unprepare(dsi->pll_clk);
> + clk_disable_unprepare(dsi->sclk_clk);
> clk_disable_unprepare(dsi->bus_clk);
>
> ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1722,10 +1715,13 @@ static int exynos_dsi_probe(struct
[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'
On 2015ë
06ì 22ì¼ 20:59, Krzysztof Kozlowski wrote:
> 2015-06-22 20:42 GMT+09:00 Inki Dae :
>> + Krzysztof
>>
>> On 2015ë
06ì 22ì¼ 18:10, Inki Dae wrote:
>>> On 2015ë
06ì 12ì¼ 21:59, Hyungwon Hwang wrote:
>>>> The clock which was named as 'pll_clk' is actually not the clock source
>>>> of PLL in MIPI DSI. This patch fixes this disagreement.
>>>
>>> Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd
>>> like to merge this patch to mainline through drm-next.
>
> Dear Hyungwon Hwang,
>
> Please always CC samsung-soc mailing list on such patches. I won't
> receive it on my personal email if you don't CC the list. The
> get_maintainers.pl gives necessary addresses.
>
> Comment below,
>
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>> Signed-off-by: Hyungwon Hwang
>>>> ---
>>>> Changes before:
>>>> - Refer https://patchwork.kernel.org/patch/6191811
>>>> Changes for v6:
>>>> - None
>>>>
>>>> arch/arm/boot/dts/exynos4.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos4.dtsi
>>>> b/arch/arm/boot/dts/exynos4.dtsi
>>>> index e20cdc2..1538d7a 100644
>>>> --- a/arch/arm/boot/dts/exynos4.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>>>> @@ -167,7 +167,7 @@
>>>> phys = <_phy 1>;
>>>> phy-names = "dsim";
>>>> clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
>>>> -clock-names = "bus_clk", "pll_clk";
>>>> +clock-names = "bus_clk", "sclk_mipi";
>
> It seems wrong. The driver fetches reference from a name of "pll_clk",
> not "sclk_mipi". Also bindings documentation mentions pll_clk and
> bus_clk only.
Krzysztof,
There is your missing point. The driver is already considered for
pll_clk also. See the below codes,
#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
...
for (i = 0; i < dsi->driver_data->num_clks; i++) {
dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
if (IS_ERR(dsi->clks[i])) {
if (strcmp(clk_names[i], "sclk_mipi") == 0) {
strcpy(clk_names[i], OLD_SCLK_MIPI_CLK_NAME);
i--;
continue;
}
dev_info(dev, "failed to get the clock: %s\n",
clk_names[i]);
return PTR_ERR(dsi->clks[i]);
}
}
Above codes make the driver to try to get the pll_clk - defined as
OLD_SCLK_MIPI_CLK_NAME macro - again if getting sclk_mipi clock failed
so there is no problem even though a little bit ugly.
As you know, we should guarantee the backward compatibility so this
codes check two clock names.
Thanks,
Inki Dae
>
> Best regards,
> Krzysztof
>
>
>>>> status = "disabled";
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
>
[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver
On 2015ë
06ì 22ì¼ 20:41, Varka Bhadram wrote:
> Hi,
>
> On 06/22/2015 04:46 PM, Inki Dae wrote:
>
>> From: Joonyoung Shim
>>
>> DECON(Display and Enhancement Controller) is new IP replacing FIMD in
>> Exynos5433. This patch adds Exynos5433 decon driver.
>>
>> Changelog v7:
>> - Rebased on top of exynos-drm-next.
>> - Added runtime pm support.
>>
>> Signed-off-by: Joonyoung Shim
>> Signed-off-by: Hyungwon Hwang
>> Signed-off-by: Inki Dae
>> ---
>>
>
> (...)
>
>> +static int exynos5433_decon_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct decon_context *ctx;
>> +struct resource *res;
>> +int ret;
>> +int i;
>> +
>> +ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> +if (!ctx)
>> +return -ENOMEM;
>> +
>> +ctx->default_win = 0;
>> +ctx->suspended = true;
>> +ctx->dev = dev;
>> +if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>> +ctx->i80_if = true;
>> +
>> +for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>> +struct clk *clk;
>> +
>> +clk = devm_clk_get(ctx->dev, decon_clks_name[i]);
>> +if (IS_ERR(clk))
>> +return PTR_ERR(clk);
>> +
>> +ctx->clks[i] = clk;
>> +}
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +if (!res) {
>> +dev_err(dev, "cannot find IO resource\n");
>> +return -ENXIO;
>> +}
>> +
>
> You people promised me to remove this check :-)
Right but isn't it better to check an error explicitly? Anyway trivial one.
>
> http://lists.freedesktop.org/archives/dri-devel/2015-April/081077.html
>
>> +ctx->addr = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(ctx->addr)) {
>> +dev_err(dev, "ioremap failed\n");
>> +return PTR_ERR(ctx->addr);
>> +}
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> +ctx->i80_if ? "lcd_sys" : "vsync");
>> +if (!res) {
>> +dev_err(dev, "cannot find IRQ resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +ret = devm_request_irq(dev, res->start, ctx->i80_if ?
>> +decon_lcd_sys_irq_handler : decon_vsync_irq_handler, 0,
>> +"drm_decon", ctx);
>> +if (ret < 0) {
>> +dev_err(dev, "lcd_sys irq request failed\n");
>> +return ret;
>> +}
>> +
>> +platform_set_drvdata(pdev, ctx);
>
> You are setting the driver data as ctx..
>
> But no where you are using it...?
>
> Am i missing anything ?
See decon_bind and decon_unbind functions. :)
Thanks,
Inki Dae
>
[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'
+ Krzysztof On 2015ë 06ì 22ì¼ 18:10, Inki Dae wrote: > On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote: >> The clock which was named as 'pll_clk' is actually not the clock source >> of PLL in MIPI DSI. This patch fixes this disagreement. > > Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd > like to merge this patch to mainline through drm-next. > > Thanks, > Inki Dae > >> >> Signed-off-by: Hyungwon Hwang >> --- >> Changes before: >> - Refer https://patchwork.kernel.org/patch/6191811 >> Changes for v6: >> - None >> >> arch/arm/boot/dts/exynos4.dtsi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi >> index e20cdc2..1538d7a 100644 >> --- a/arch/arm/boot/dts/exynos4.dtsi >> +++ b/arch/arm/boot/dts/exynos4.dtsi >> @@ -167,7 +167,7 @@ >> phys = <_phy 1>; >> phy-names = "dsim"; >> clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>; >> -clock-names = "bus_clk", "pll_clk"; >> +clock-names = "bus_clk", "sclk_mipi"; >> status = "disabled"; >> #address-cells = <1>; >> #size-cells = <0>; >> -- >> 1.9.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
[PATCH v7 05/15] drm/exynos: add Exynos5433 decon driver
From: Joonyoung Shim <jy0922.s...@samsung.com>
DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.
Changelog v7:
- Rebased on top of exynos-drm-next.
- Added runtime pm support.
Signed-off-by: Joonyoung Shim
Signed-off-by: Hyungwon Hwang
Signed-off-by: Inki Dae
---
.../devicetree/bindings/video/exynos5433-decon.txt | 65 ++
drivers/gpu/drm/exynos/Kconfig |6 +
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 660
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos5433_decon.h | 165 +
6 files changed, 898 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
create mode 100644 include/video/exynos5433_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+ in the same order as they were listed in the interrupts
+ property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+ "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+ "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+ node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon at 1380 {
+ compatible = "samsung,exynos5433-decon";
+ reg = <0x1380 0x2104>;
+ clocks = <_disp CLK_ACLK_DECON>, <_disp CLK_ACLK_SMMU_DECON0X>,
+ <_disp CLK_ACLK_XIU_DECON0X>,
+ <_disp CLK_PCLK_SMMU_DECON0X>,
+ <_disp CLK_SCLK_DECON_VCLK>,
+ <_disp CLK_SCLK_DECON_ECLK>;
+ clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+ "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+ interrupt-names = "vsync", "lcd_sys";
+ interrupts = <0 202 0>, <0 203 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ decon_to_mic: endpoint {
+ remote-endpoint = <_to_decon>;
+ };
+ };
+ };
+};
+
+Board specific DT entry:
+ {
+ i80-if-timings {
+ };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index ddb7c8a..51a4eb5 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,6 +24,12 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS5433_DECON
+ bool "Exynos5433 DRM DECON"
+ depends on DRM_EXYNOS
+ help
+ Choose this option if you want to use Exynos5433 DECON for DRM.
+
config DRM_EXYNOS7_DECON
bool "Exynos7 DRM DECON"
depends on DRM_EXYNOS &
[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'
On 2015ë 06ì 12ì¼ 21:59, Hyungwon Hwang wrote: > The clock which was named as 'pll_clk' is actually not the clock source > of PLL in MIPI DSI. This patch fixes this disagreement. Mr. Kukjin and Krzysztof, can you give me Acked-by or Singed-off-by? I'd like to merge this patch to mainline through drm-next. Thanks, Inki Dae > > Signed-off-by: Hyungwon Hwang > --- > Changes before: > - Refer https://patchwork.kernel.org/patch/6191811 > Changes for v6: > - None > > arch/arm/boot/dts/exynos4.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi > index e20cdc2..1538d7a 100644 > --- a/arch/arm/boot/dts/exynos4.dtsi > +++ b/arch/arm/boot/dts/exynos4.dtsi > @@ -167,7 +167,7 @@ > phys = <_phy 1>; > phy-names = "dsim"; > clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>; > - clock-names = "bus_clk", "pll_clk"; > + clock-names = "bus_clk", "sclk_mipi"; > status = "disabled"; > #address-cells = <1>; > #size-cells = <0>; > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH v10 00/17] drm/exynos: atomic modesetting support
On 2015ë 06ì 17ì¼ 23:33, Gustavo Padovan wrote: > Hi Inki, > > 2015-06-17 Inki Dae : > >> Hi Gustavo, >> >> On 2015ë 06ì 17ì¼ 05:35, Gustavo Padovan wrote: >>> HI Inki, >>> >>> 2015-06-15 Inki Dae : >>> >>>> Hi Gustavo, >>>> >>>> On 2015ë 06ì 02ì¼ 00:04, Gustavo Padovan wrote: >>>>> From: Gustavo Padovan >>>>> >>>>> Hi, >>>>> >>>>> Here goes the full support for atomic modesetting on exynos. I've >>>>> split the patches in the various phases of atomic support. >>>>> >>>>> v2: fixes comments by Joonyoung >>>>> - remove unused var in patch 09 >>>>> - use ->disable instead of outdated ->dpms in hdmi code >>>>> - remove WARN_ON from crtc enable/disable >>>>> >>>>> v3: fixes comment by Joonyoung >>>>> - move the removal of drm_helper_disable_unused_functions() to >>>>> separated patch >>>>> >>>>> v4: add patches that remove unnecessary calls to disable_plane() >>>>> >>>>> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) >>>>> >>>>> v6: rebase on latest exynos_drm_next >>>>> >>>>> v7: fix comments by Joonyoung >>>>> - fix two checkpatch errors >>>>> - remove extra crtc->commit() call >>>>> - check for null fb on exynos_check_plane() >>>>> >>>>> v8: fix comments by Joonyoung >>>>> - fix merge error >>>>> - move drm_crtc_vblank_get to the commit that introduces atomic >>>>> pageflip >>>>> - remove .prepare() in the apropiated patch >>>>> - add a new patch to move exynos_drm_crtc_disable() >>>>> >>>>> v9: * fix comments by Joonyoung >>>>> - also remove encoder .prepare() >>>>> - do not shift exynos_update_plane() parameters >>>>> - remove unused .mode_set() and .mode_set_base() >>>>> * add specific exynos .atomic_commit() >>>>> * add split of exynos_crtc->ops->dpms() into enable() and disable() >>>>> * add other atomic clean ups >>>>> >>>>> v10: * fix comments by Joonyoung >>>>> - add more comments on exynos_atomic_commit() >>>>> - make exynos_crtc's .enable and .disable void >>>> >>>> I found out one issue that refresh rate gets low with display extension >>>> mode test. >>>> >>>> I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here >>>> is how to test it, >>>> >>>> #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection >>>> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >>>> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >>>> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >>>> freq: 20.00Hz >>>> freq: 20.00Hz >>>> >>>> As you can see, refresh rate is 20. >>>> >>>> Below is the result without atomic patch series, >>>> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >>>> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >>>> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >>>> freq: 60.18Hz >>>> freq: 49.09Hz >>>> >>>> I can see 60Hz for FIMD and 49Hz for vidi. >>> >>> I gave this a try and figured out that this might be a vidi specific >>> problem. If I try VIDI and FIMD I get the same results as you but with >>> Mixer and FIMD(the setup I actually use to test) everything works fine. >> >> Hm... Did Mixer and FIMD combination really work correctly with >> extension mode? > > Yes. > > collabora at singularity:~$ modetest -M exynos -s 31:1920x1080 -v -s > 25:1366x768 > setting mode 1920x1080-60Hz at XR24 on connectors 31, crtc 29 > setting mode 1366x768-60Hz at XR24 on connectors 25, crtc 23 > freq: 55.82Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz Your patch series had one bug that the vblank operation was duplicated. As you may know, the page flip opera
[PATCH] drm/exynos: do not wait for vblank at atomic operation
This patch resolves the issue that refresh rate got low at extension mode test with fimd and vidi combination. The problem was because atomic_commit callback waited for the completion of vblank to gaurantee crtc relevant registers are updated from shadow registers to real ones. However, the waiting there is really unnecessary because page flip operation does already it. Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_fb.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 789db6f..2b6320e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -295,8 +295,6 @@ static int exynos_atomic_commit(struct drm_device *dev, drm_atomic_helper_commit_planes(dev, state); - drm_atomic_helper_wait_for_vblanks(dev, state); - drm_atomic_helper_cleanup_planes(dev, state); drm_atomic_state_free(state); -- 1.7.9.5
[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj
On 2015ë
06ì 19ì¼ 14:46, Krzysztof Kozlowski wrote:
> 2015-06-19 14:28 GMT+09:00 Inki Dae :
>> On 2015ë
06ì 19ì¼ 14:23, Krzysztof Kozlowski wrote:
>>> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
>>> 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
>>> not referenced anywhere.
>>>
>>> One instance of 'exynos_drm_gem_obj' may be mapped to multiple
>>> user-space VMAs so 'vma' field does not look useful anyway.
>>
>> Krzysztof,
>>
>> The vma member would be removed by below patch,
>> http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
>>
>
> I think it is a different object. The patch above removes it from
> struct g2d_cmdlist_userptr.
> However I removed it from struct exynos_drm_gem_obj, where it was
> never referenced.
Ah, right. There was my mistake.
Thanks,
Inki Dae
>
> Best regards,
> Krzysztof
>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>>> 1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 308173cb4f0a..6f42e2248288 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>>> * or at framebuffer creation.
>>> * @size: size requested from user, in bytes and this size is aligned
>>> * in page unit.
>>> - * @vma: a pointer to vm_area.
>>> * @flags: indicate memory type to allocated buffer and cache attruibute.
>>> *
>>> * P.S. this object would be transferred to user as kms_bo.handle so
>>> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>>> struct drm_gem_object base;
>>> struct exynos_drm_gem_buf *buffer;
>>> unsigned long size;
>>> - struct vm_area_struct *vma;
>>> unsigned intflags;
>>> };
>>>
>>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj
On 2015ë
06ì 19ì¼ 14:23, Krzysztof Kozlowski wrote:
> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
> 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
> not referenced anywhere.
>
> One instance of 'exynos_drm_gem_obj' may be mapped to multiple
> user-space VMAs so 'vma' field does not look useful anyway.
Krzysztof,
The vma member would be removed by below patch,
http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
Thanks,
Inki Dae
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 308173cb4f0a..6f42e2248288 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
> * or at framebuffer creation.
> * @size: size requested from user, in bytes and this size is aligned
> * in page unit.
> - * @vma: a pointer to vm_area.
> * @flags: indicate memory type to allocated buffer and cache attruibute.
> *
> * P.S. this object would be transferred to user as kms_bo.handle so
> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
> struct drm_gem_object base;
> struct exynos_drm_gem_buf *buffer;
> unsigned long size;
> - struct vm_area_struct *vma;
> unsigned intflags;
> };
>
>
[PATCH v10 00/17] drm/exynos: atomic modesetting support
On 2015ë 06ì 17ì¼ 23:33, Gustavo Padovan wrote: > Hi Inki, > > 2015-06-17 Inki Dae : > >> Hi Gustavo, >> >> On 2015ë 06ì 17ì¼ 05:35, Gustavo Padovan wrote: >>> HI Inki, >>> >>> 2015-06-15 Inki Dae : >>> >>>> Hi Gustavo, >>>> >>>> On 2015ë 06ì 02ì¼ 00:04, Gustavo Padovan wrote: >>>>> From: Gustavo Padovan >>>>> >>>>> Hi, >>>>> >>>>> Here goes the full support for atomic modesetting on exynos. I've >>>>> split the patches in the various phases of atomic support. >>>>> >>>>> v2: fixes comments by Joonyoung >>>>> - remove unused var in patch 09 >>>>> - use ->disable instead of outdated ->dpms in hdmi code >>>>> - remove WARN_ON from crtc enable/disable >>>>> >>>>> v3: fixes comment by Joonyoung >>>>> - move the removal of drm_helper_disable_unused_functions() to >>>>> separated patch >>>>> >>>>> v4: add patches that remove unnecessary calls to disable_plane() >>>>> >>>>> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) >>>>> >>>>> v6: rebase on latest exynos_drm_next >>>>> >>>>> v7: fix comments by Joonyoung >>>>> - fix two checkpatch errors >>>>> - remove extra crtc->commit() call >>>>> - check for null fb on exynos_check_plane() >>>>> >>>>> v8: fix comments by Joonyoung >>>>> - fix merge error >>>>> - move drm_crtc_vblank_get to the commit that introduces atomic >>>>> pageflip >>>>> - remove .prepare() in the apropiated patch >>>>> - add a new patch to move exynos_drm_crtc_disable() >>>>> >>>>> v9: * fix comments by Joonyoung >>>>> - also remove encoder .prepare() >>>>> - do not shift exynos_update_plane() parameters >>>>> - remove unused .mode_set() and .mode_set_base() >>>>> * add specific exynos .atomic_commit() >>>>> * add split of exynos_crtc->ops->dpms() into enable() and disable() >>>>> * add other atomic clean ups >>>>> >>>>> v10: * fix comments by Joonyoung >>>>> - add more comments on exynos_atomic_commit() >>>>> - make exynos_crtc's .enable and .disable void >>>> >>>> I found out one issue that refresh rate gets low with display extension >>>> mode test. >>>> >>>> I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here >>>> is how to test it, >>>> >>>> #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection >>>> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >>>> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >>>> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >>>> freq: 20.00Hz >>>> freq: 20.00Hz >>>> >>>> As you can see, refresh rate is 20. >>>> >>>> Below is the result without atomic patch series, >>>> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >>>> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >>>> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >>>> freq: 60.18Hz >>>> freq: 49.09Hz >>>> >>>> I can see 60Hz for FIMD and 49Hz for vidi. >>> >>> I gave this a try and figured out that this might be a vidi specific >>> problem. If I try VIDI and FIMD I get the same results as you but with >>> Mixer and FIMD(the setup I actually use to test) everything works fine. >> >> Hm... Did Mixer and FIMD combination really work correctly with >> extension mode? > > Yes. > > collabora at singularity:~$ modetest -M exynos -s 31:1920x1080 -v -s > 25:1366x768 > setting mode 1920x1080-60Hz at XR24 on connectors 31, crtc 29 > setting mode 1366x768-60Hz at XR24 on connectors 25, crtc 23 > freq: 55.82Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > freq: 55.30Hz > freq: 55.38Hz > >> >>> So somehow my patches caused a regression on vidi that I'm still >>> ivestigat
[PATCH v10 00/17] drm/exynos: atomic modesetting support
Hi Gustavo, On 2015ë 06ì 17ì¼ 05:35, Gustavo Padovan wrote: > HI Inki, > > 2015-06-15 Inki Dae : > >> Hi Gustavo, >> >> On 2015ë 06ì 02ì¼ 00:04, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> Here goes the full support for atomic modesetting on exynos. I've >>> split the patches in the various phases of atomic support. >>> >>> v2: fixes comments by Joonyoung >>> - remove unused var in patch 09 >>> - use ->disable instead of outdated ->dpms in hdmi code >>> - remove WARN_ON from crtc enable/disable >>> >>> v3: fixes comment by Joonyoung >>> - move the removal of drm_helper_disable_unused_functions() to >>> separated patch >>> >>> v4: add patches that remove unnecessary calls to disable_plane() >>> >>> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias) >>> >>> v6: rebase on latest exynos_drm_next >>> >>> v7: fix comments by Joonyoung >>> - fix two checkpatch errors >>> - remove extra crtc->commit() call >>> - check for null fb on exynos_check_plane() >>> >>> v8: fix comments by Joonyoung >>> - fix merge error >>> - move drm_crtc_vblank_get to the commit that introduces atomic >>> pageflip >>> - remove .prepare() in the apropiated patch >>> - add a new patch to move exynos_drm_crtc_disable() >>> >>> v9: * fix comments by Joonyoung >>> - also remove encoder .prepare() >>> - do not shift exynos_update_plane() parameters >>> - remove unused .mode_set() and .mode_set_base() >>> * add specific exynos .atomic_commit() >>> * add split of exynos_crtc->ops->dpms() into enable() and disable() >>> * add other atomic clean ups >>> >>> v10: * fix comments by Joonyoung >>> - add more comments on exynos_atomic_commit() >>> - make exynos_crtc's .enable and .disable void >> >> I found out one issue that refresh rate gets low with display extension >> mode test. >> >> I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here >> is how to test it, >> >> #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >> freq: 20.00Hz >> freq: 20.00Hz >> >> As you can see, refresh rate is 20. >> >> Below is the result without atomic patch series, >> # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480 >> setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29 >> setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21 >> freq: 60.18Hz >> freq: 49.09Hz >> >> I can see 60Hz for FIMD and 49Hz for vidi. > > I gave this a try and figured out that this might be a vidi specific > problem. If I try VIDI and FIMD I get the same results as you but with > Mixer and FIMD(the setup I actually use to test) everything works fine. Hm... Did Mixer and FIMD combination really work correctly with extension mode? > So somehow my patches caused a regression on vidi that I'm still > ivestigating. I think this issue is because page flip operations are performed in atomic: if I see correctly, when page flip is requested by modetest, the call flow is as follows, drm_atomic_helper_page_flip drm_atomic_async_commit exynos_atomic_commit ... drm_atomic_helper_wait_for_vblanks ... However, the function, drm_atomic_helper_wait_for_vblanks called by exynos_atomic_commit, waits for the vblank completion of each crtc driver . See wait_event_timeout function call in drm_atomic_helper_wait_for_vblanks function. This means that a page flip request of a crtc driver cannot be performed until the vblank completion of another crtc driver. I think you should have implemented exynos_atomic_commit function asynchronously, not synchronously like you did. So it seems that this function should be re-implemented. If my analysis is correct and you cannot post the change set within this week, I'm not sure whether the atomic patch series should go to mainline. Anyway, I will decide it and have a pull-request at the end of this week at least. Thanks, Inki Dae > > Gustavo > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
