[PATCH 0/7] add atomic_check callback to exynos_crtc
On 28.10.2015 14:38, Krzysztof Kozlowski wrote: > On 28.10.2015 14:30, Inki Dae wrote: >> >> >> 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. > > So this is not a build-time dependency but rather runtime? What will > happen if HDMI is compiled and enabled (for example in DTB) but there > will be no DECON nor MIXER compiled in? > Okay, I received the explanation off-line. :) The solution looks good to me, I'll give the respective tags for individual patches (please submit also multi_v7). Best regards, Krzysztof
[PATCH 0/7] add atomic_check callback to exynos_crtc
On 28.10.2015 14:30, Inki Dae wrote: > > > 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. So this is not a build-time dependency but rather runtime? What will happen if HDMI is compiled and enabled (for example in DTB) but there will be no DECON nor MIXER compiled in? Best regards, Krzysztof
[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 0/7] add atomic_check callback to exynos_crtc
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? Best regards, Krzysztof
[PATCH 0/7] add atomic_check callback to exynos_crtc
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 :) Regards Andrzej Andrzej Hajda (7): drm/exynos: add atomic_check callback to exynos_crtc drm/exynos/mixer: replace direct cross-driver call with drm mode validation ARM: exynos_defconfig: enable Exynos DRM Mixer driver 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 arch/arm/configs/exynos_defconfig| 1 + drivers/gpu/drm/exynos/Kconfig | 75 +++- drivers/gpu/drm/exynos/Makefile | 3 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 5 --- drivers/gpu/drm/exynos/exynos_mixer.c| 6 ++- drivers/gpu/drm/exynos/exynos_mixer.h| 20 - 9 files changed, 69 insertions(+), 60 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h -- 1.9.1
