| Message ID | 1427471856-20918-1-git-send-email-k.kozlowski@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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! -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(+)