Krzysztof Kozlowski <[email protected]> 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 <[email protected]>
> Reported-by: Javier Martinez Canillas <[email protected]>
> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
> Cc: <[email protected]>
>
> ---
>
> 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
2015-04-30 2:31 GMT+09:00 Kevin Hilman <[email protected]>:
> Krzysztof Kozlowski <[email protected]> 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 <[email protected]>
>> Reported-by: Javier Martinez Canillas <[email protected]>
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc: <[email protected]>
>>
>> ---
>>
>> 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
Krzysztof Kozlowski <[email protected]> writes:
> 2015-04-30 2:31 GMT+09:00 Kevin Hilman <[email protected]>:
>> Krzysztof Kozlowski <[email protected]> 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 <[email protected]>
>>> Reported-by: Javier Martinez Canillas <[email protected]>
>>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>>> Cc: <[email protected]>
>>>
>>> ---
>>>
>>> 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
On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <[email protected]> wrote:
> Krzysztof Kozlowski <[email protected]> writes:
>
>> 2015-04-30 2:31 GMT+09:00 Kevin Hilman <[email protected]>:
>>> Krzysztof Kozlowski <[email protected]> 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 <[email protected]>
>>>> Reported-by: Javier Martinez Canillas <[email protected]>
>>>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>>>> Cc: <[email protected]>
>>>>
>>>> ---
>>>>
>>>> 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
Hello Olof,
On 04/30/2015 05:57 PM, Olof Johansson wrote:
> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <[email protected]> wrote:
>> Krzysztof Kozlowski <[email protected]> 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
On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
<[email protected]> wrote:
> Hello Olof,
>
> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <[email protected]> wrote:
>>> Krzysztof Kozlowski <[email protected]> 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
2015-05-01 1:50 GMT+09:00 Olof Johansson <[email protected]>:
> On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
> <[email protected]> wrote:
>> Hello Olof,
>>
>> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <[email protected]> wrote:
>>>> Krzysztof Kozlowski <[email protected]> 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!