2015-05-01 1:50 GMT+09:00 Olof Johansson <olof@xxxxxxxxx>: > On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas > <javier.martinez@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote: >>>> Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
