[adding Inki to cc list]
Hello Guillaume,
On 12/12/2017 11:43 AM, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@xxxxxxxxxx> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@xxxxxxxxxx>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@xxxxxxxxxxxxx>
>
>
> Thanks for the fix!
>
Thanks for testing!
Now, I think the exynos-drm driver should cope with an incorrect DTB and
don't crash the machine, the driver should only fail to probe and lead
to a working machine with no display.
But as mentioned, that's a different issue and orthogonal to the DTS fix.
> Guillaume
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
