From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Inki Dae <inki.dae@samsung.com>, Andrzej Hajda <a.hajda@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
"open list:DRM DRIVERS FOR EXYNOS"
<dri-devel@lists.freedesktop.org>,
"moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES"
<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH 0/7] add atomic_check callback to exynos_crtc
Date: Wed, 28 Oct 2015 14:57:28 +0900 [thread overview]
Message-ID: <563063C8.2040202@samsung.com> (raw)
In-Reply-To: <56305F44.405@samsung.com>
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
next prev parent reply other threads:[~2015-10-28 5:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 12:03 [PATCH 0/7] add atomic_check callback to exynos_crtc Andrzej Hajda
2015-10-26 12:03 ` [PATCH 1/7] drm/exynos: " Andrzej Hajda
2015-10-26 12:03 ` [PATCH 2/7] drm/exynos/mixer: replace direct cross-driver call with drm mode validation Andrzej Hajda
2015-11-24 21:40 ` Javier Martinez Canillas
2015-11-27 6:57 ` [PATCH] drm/exynos: atomic check only enabled crtc states Andrzej Hajda
2015-11-27 13:00 ` Javier Martinez Canillas
2015-12-09 10:51 ` Javier Martinez Canillas
2015-12-11 15:18 ` Inki Dae
2015-10-26 12:03 ` [PATCH 3/7] ARM: exynos_defconfig: enable Exynos DRM Mixer driver Andrzej Hajda
2015-10-28 6:09 ` Krzysztof Kozlowski
2015-10-28 6:15 ` Inki Dae
2016-05-30 6:37 ` Krzysztof Kozlowski
2015-10-26 12:03 ` [PATCH 4/7] drm/exynos: separate Mixer and HDMI drivers Andrzej Hajda
2015-10-26 12:03 ` [PATCH 5/7] drm/exynos: abstract out common dependency Andrzej Hajda
2015-10-26 12:03 ` [PATCH 6/7] drm/exynos: re-arrange Kconfig entries Andrzej Hajda
2015-10-26 12:03 ` [PATCH 7/7] drm/exynos: simplify Kconfig component names Andrzej Hajda
2015-10-28 1:37 ` [PATCH 0/7] add atomic_check callback to exynos_crtc Krzysztof Kozlowski
2015-10-28 5:30 ` Inki Dae
2015-10-28 5:38 ` Krzysztof Kozlowski
2015-10-28 5:57 ` Krzysztof Kozlowski [this message]
2015-10-29 14:25 ` [PATCH] ARM: multi_v7_defconfig: enable Exynos DRM Mixer driver Andrzej Hajda
2015-10-30 0:47 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563063C8.2040202@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=a.hajda@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.