diff mbox

[RFT] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

Message ID 1427471856-20918-1-git-send-email-k.kozlowski@samsung.com (mailing list archive)
State New, archived
Headers show

Commit Message

Krzysztof Kozlowski March 27, 2015, 3:57 p.m. UTC
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.

The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.

When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:

exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
Cc: <stable@vger.kernel.org>

---

This should fix issue reported by Javier [1][2].

Tested on Chromebook Snow (Exynos 5250). More testing would be great,
especially on other Exynos 5xxx products.

[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/43889
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/400290
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  | 10 ++++++++++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++++++++++++++++++
 include/video/samsung_fimd.h             |  6 ++++++
 3 files changed, 35 insertions(+)

Comments

Kevin Hilman April 29, 2015, 5:31 p.m. UTC | #1
Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:

> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
>
> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
> This clock is required by Display Port and is enabled by bootloader.
> However when FIMD driver probing was deferred, the display power domain
> was turned off. This effectively reset the value of DP clock enable
> register.
>
> When exynos-dp is later probed, the clock is not enabled and display is
> not properly configured:
>
> exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
> exynos-dp 145b0000.dp-controller: unable to config video
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
> Cc: <stable@vger.kernel.org>
>
> ---
>
> This should fix issue reported by Javier [1][2].
>
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> especially on other Exynos 5xxx products.

I hoped to try this on my exynos5 boards, but it doesn't seem to apply
to linux-next or to Linus' master branch.

Are there some other dependencies here?

Kevin
Krzysztof Kozlowski April 29, 2015, 11:56 p.m. UTC | #2
2015-04-30 2:31 GMT+09:00 Kevin Hilman <khilman@kernel.org>:
> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>> This clock is required by Display Port and is enabled by bootloader.
>> However when FIMD driver probing was deferred, the display power domain
>> was turned off. This effectively reset the value of DP clock enable
>> register.
>>
>> When exynos-dp is later probed, the clock is not enabled and display is
>> not properly configured:
>>
>> exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
>> exynos-dp 145b0000.dp-controller: unable to config video
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc: <stable@vger.kernel.org>
>>
>> ---
>>
>> This should fix issue reported by Javier [1][2].
>>
>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>> especially on other Exynos 5xxx products.
>
> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
> to linux-next or to Linus' master branch.
>
> Are there some other dependencies here?

It is already applied:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc

Best regards,
Krzysztof
Kevin Hilman April 30, 2015, 3:44 p.m. UTC | #3
Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:

> 2015-04-30 2:31 GMT+09:00 Kevin Hilman <khilman@kernel.org>:
>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>
>>> After adding display power domain for Exynos5250 in commit
>>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>>> display on Chromebook Snow and others stopped working after boot.
>>>
>>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>>> This clock is required by Display Port and is enabled by bootloader.
>>> However when FIMD driver probing was deferred, the display power domain
>>> was turned off. This effectively reset the value of DP clock enable
>>> register.
>>>
>>> When exynos-dp is later probed, the clock is not enabled and display is
>>> not properly configured:
>>>
>>> exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
>>> exynos-dp 145b0000.dp-controller: unable to config video
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>> Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>>> Cc: <stable@vger.kernel.org>
>>>
>>> ---
>>>
>>> This should fix issue reported by Javier [1][2].
>>>
>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>> especially on other Exynos 5xxx products.
>>
>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>> to linux-next or to Linus' master branch.
>>
>> Are there some other dependencies here?
>
> It is already applied:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc

Er, yup.  That would explain it. ;)

Sorry for the noise,

Kevin
Olof Johansson April 30, 2015, 3:57 p.m. UTC | #4
On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <khilman@kernel.org> wrote:
> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>
>> 2015-04-30 2:31 GMT+09:00 Kevin Hilman <khilman@kernel.org>:
>>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>>
>>>> After adding display power domain for Exynos5250 in commit
>>>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>>>> display on Chromebook Snow and others stopped working after boot.
>>>>
>>>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>>>> This clock is required by Display Port and is enabled by bootloader.
>>>> However when FIMD driver probing was deferred, the display power domain
>>>> was turned off. This effectively reset the value of DP clock enable
>>>> register.
>>>>
>>>> When exynos-dp is later probed, the clock is not enabled and display is
>>>> not properly configured:
>>>>
>>>> exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
>>>> exynos-dp 145b0000.dp-controller: unable to config video
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>>> Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>>>> Cc: <stable@vger.kernel.org>
>>>>
>>>> ---
>>>>
>>>> This should fix issue reported by Javier [1][2].
>>>>
>>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>>> especially on other Exynos 5xxx products.
>>>
>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>> to linux-next or to Linus' master branch.
>>>
>>> Are there some other dependencies here?
>>
>> It is already applied:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>
> Er, yup.  That would explain it. ;)
>
> Sorry for the noise,

Well, noise or not, Exynos is still broken in mainline and was broken
on -next for so long in different ways that bisecting it is a futile
exercise in frustration.

It doesn't seem to show up with a trivial boot using only ramdisk, but
when booting a real distro from disk, it certainly does.

For example:

http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html

Disabling CONFIG_DRM makes it boot reliably.

Arndale doesn't show it for me, but it also doesn't have working graphics.


-Olof
Javier Martinez Canillas April 30, 2015, 4:40 p.m. UTC | #5
Hello Olof,

On 04/30/2015 05:57 PM, Olof Johansson wrote:
> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>>>>
>>>>> This should fix issue reported by Javier [1][2].
>>>>>
>>>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>>>> especially on other Exynos 5xxx products.
>>>>
>>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>>> to linux-next or to Linus' master branch.
>>>>
>>>> Are there some other dependencies here?
>>>
>>> It is already applied:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>>
>> Er, yup.  That would explain it. ;)
>>
>> Sorry for the noise,
> 
> Well, noise or not, Exynos is still broken in mainline and was broken
> on -next for so long in different ways that bisecting it is a futile
> exercise in frustration.
> 
> It doesn't seem to show up with a trivial boot using only ramdisk, but
> when booting a real distro from disk, it certainly does.
> 
> For example:
> 
> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
> 
> Disabling CONFIG_DRM makes it boot reliably.
> 
> Arndale doesn't show it for me, but it also doesn't have working graphics.
>

Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
power domain on Exynos5420" patch that was posted a long time ago. I have
pinged Kukjin several times about this patch and he said that he will pick
it this weekend [0].

It is indeed very frustrating how many Exynos patches seems to be falling
through the crack, even important fixes like these ones that allow boards
to boot again.

Kevin suggested that Krzysztof could collect and queue patches [1] to help
Kukjin and start acting as a co-maintatiner which I think it's a very good
idea and Krzysztof already did for some patches during the 4.1 cycle.

> 
> -Olof
>

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/4/29/781
[1]: https://lkml.org/lkml/2015/4/30/576
[2]: https://lkml.org/lkml/2015/3/11/403
Olof Johansson April 30, 2015, 4:50 p.m. UTC | #6
On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Olof,
>
> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>>>>>
>>>>>> This should fix issue reported by Javier [1][2].
>>>>>>
>>>>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>>>>> especially on other Exynos 5xxx products.
>>>>>
>>>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>>>> to linux-next or to Linus' master branch.
>>>>>
>>>>> Are there some other dependencies here?
>>>>
>>>> It is already applied:
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>>>
>>> Er, yup.  That would explain it. ;)
>>>
>>> Sorry for the noise,
>>
>> Well, noise or not, Exynos is still broken in mainline and was broken
>> on -next for so long in different ways that bisecting it is a futile
>> exercise in frustration.
>>
>> It doesn't seem to show up with a trivial boot using only ramdisk, but
>> when booting a real distro from disk, it certainly does.
>>
>> For example:
>>
>> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
>>
>> Disabling CONFIG_DRM makes it boot reliably.
>>
>> Arndale doesn't show it for me, but it also doesn't have working graphics.
>>
>
> Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
> for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
> power domain on Exynos5420" patch that was posted a long time ago. I have
> pinged Kukjin several times about this patch and he said that he will pick
> it this weekend [0].
>
> It is indeed very frustrating how many Exynos patches seems to be falling
> through the crack, even important fixes like these ones that allow boards
> to boot again.
>
> Kevin suggested that Krzysztof could collect and queue patches [1] to help
> Kukjin and start acting as a co-maintatiner which I think it's a very good
> idea and Krzysztof already did for some patches during the 4.1 cycle.

Yes, that's a much needed improvement. I suggest starting out by
collecting critical fixes like these, and we'd be happy to merge them
directly if going through Kukjin will add latency.

Krzysztof, if you can, make sure you get a PGP key setup and start
collecting signatures from kernel developers.


-Olof
Krzysztof Kozlowski May 1, 2015, 9:14 a.m. UTC | #7
2015-05-01 1:50 GMT+09:00 Olof Johansson <olof@lixom.net>:
> On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Olof,
>>
>> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>>>>>>
>>>>>>> This should fix issue reported by Javier [1][2].
>>>>>>>
>>>>>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>>>>>> especially on other Exynos 5xxx products.
>>>>>>
>>>>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>>>>> to linux-next or to Linus' master branch.
>>>>>>
>>>>>> Are there some other dependencies here?
>>>>>
>>>>> It is already applied:
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>>>>
>>>> Er, yup.  That would explain it. ;)
>>>>
>>>> Sorry for the noise,
>>>
>>> Well, noise or not, Exynos is still broken in mainline and was broken
>>> on -next for so long in different ways that bisecting it is a futile
>>> exercise in frustration.
>>>
>>> It doesn't seem to show up with a trivial boot using only ramdisk, but
>>> when booting a real distro from disk, it certainly does.
>>>
>>> For example:
>>>
>>> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
>>>
>>> Disabling CONFIG_DRM makes it boot reliably.
>>>
>>> Arndale doesn't show it for me, but it also doesn't have working graphics.
>>>
>>
>> Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
>> for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
>> power domain on Exynos5420" patch that was posted a long time ago. I have
>> pinged Kukjin several times about this patch and he said that he will pick
>> it this weekend [0].
>>
>> It is indeed very frustrating how many Exynos patches seems to be falling
>> through the crack, even important fixes like these ones that allow boards
>> to boot again.
>>
>> Kevin suggested that Krzysztof could collect and queue patches [1] to help
>> Kukjin and start acting as a co-maintatiner which I think it's a very good
>> idea and Krzysztof already did for some patches during the 4.1 cycle.

Yes, I did. It turned quite well, most of the patches I collected were
pulled :) .

> Yes, that's a much needed improvement. I suggest starting out by
> collecting critical fixes like these, and we'd be happy to merge them
> directly if going through Kukjin will add latency.
>
> Krzysztof, if you can, make sure you get a PGP key setup and start
> collecting signatures from kernel developers.

Sure, I'll start right away!
diff mbox

Patch

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index bf17a60b40ed..1dbfba58f909 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -32,10 +32,16 @@ 
 #include <drm/bridge/ptn3460.h>
 
 #include "exynos_dp_core.h"
+#include "exynos_drm_fimd.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->crtc);
+}
+
 static inline struct exynos_dp_device *
 display_to_dp(struct exynos_drm_display *d)
 {
@@ -1070,6 +1076,8 @@  static void exynos_dp_poweron(struct exynos_dp_device *dp)
 		}
 	}
 
+	fimd_dp_clock_enable(dp_to_crtc(dp), true);
+
 	clk_prepare_enable(dp->clock);
 	exynos_dp_phy_init(dp);
 	exynos_dp_init_dp(dp);
@@ -1094,6 +1102,8 @@  static void exynos_dp_poweroff(struct exynos_dp_device *dp)
 	exynos_dp_phy_exit(dp);
 	clk_disable_unprepare(dp->clock);
 
+	fimd_dp_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_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index c300e22da8ac..bdf0818dc8f5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -32,6 +32,7 @@ 
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_iommu.h"
+#include "exynos_drm_fimd.h"
 
 /*
  * FIMD stands for Fully Interactive Mobile Display and
@@ -1231,6 +1232,24 @@  static int fimd_remove(struct platform_device *pdev)
 	return 0;
 }
 
+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 != &exynos5_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);
+}
+EXPORT_SYMBOL_GPL(fimd_dp_clock_enable);
+
 struct platform_driver fimd_driver = {
 	.probe		= fimd_probe,
 	.remove		= fimd_remove,
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3a8b15..847a0a2b399c 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -436,6 +436,12 @@ 
 #define BLENDCON_NEW_8BIT_ALPHA_VALUE		(1 << 0)
 #define BLENDCON_NEW_4BIT_ALPHA_VALUE		(0 << 0)
 
+/* Display port clock control */
+#define DP_MIE_CLKCON				0x27c
+#define DP_MIE_CLK_DISABLE			0x0
+#define DP_MIE_CLK_DP_ENABLE			0x2
+#define DP_MIE_CLK_MIE_ENABLE			0x3
+
 /* Notes on per-window bpp settings
  *
  * Value	Win0	 Win1	  Win2	   Win3	    Win 4