mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging

[Javier Martinez Canillas]

Hello Marek,

On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
<m.szyprowski at samsung.com> wrote:
> Hi Shuah,
>
>
> On 2017-12-12 00:25, Shuah Khan wrote:
>>
>> On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
>>>
>>> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>>>>
>>>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
>>>> wrote:
>>>>>
>>>>> So I gave a quick look to this, and at the very least there's a bug in
>>>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>>>
>>>>> I've posted a fix for that:
>>>>>
>>>>> https://patchwork.kernel.org/patch/10105921/
>>>>>
>>>>> I believe this could be also be the cause for the boot failure, since
>>>>> I see in the boot log that things start to go wrong after exynos-drm
>>>>> fails to bind the HDMI component:
>>>>>
>>>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>>>> 0xc1398690): -1
>>>>
>>>> Umm, -1 ?  Looking that error code up in
>>>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>>>
>>>> I suspect that's someone just returning -1 because they're lazy...
>>>> which is real bad form and needs fixing.
>>>
>>> Oh, it really is -EPERM:
>>>
>>> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
>>> *drm_dev,
>>>                                         enum exynos_drm_output_type
>>> out_type)
>>> {
>>>          struct drm_crtc *crtc;
>>>
>>>          drm_for_each_crtc(crtc, drm_dev)
>>>                  if (to_exynos_crtc(crtc)->type == out_type)
>>>                          return to_exynos_crtc(crtc);
>>>
>>>          return ERR_PTR(-EPERM);
>>> }
>>>
>>> Does "Operation not permitted" really convey the error here?  It doesn't
>>> look like a permission error to me.
>>>
>>> Can we please avoid abusing errno codes?
>>
>> I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
>> with top commit g968edbd worked just fine for me last Friday. I ran
>> several
>> tests and everything checked out except the exynos-gsc lockdep issue I
>> sent
>> a 4.14 patch for.
>>
>> However, with 4.15-rc3, dmesg is gets filled with
>>
>> [  342.337181] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  342.337470] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  342.337851] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.382346] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.396682] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.399244] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.399496] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.399848] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.400163] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.400495] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.401294] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>> [  402.401595] [drm] Non-contiguous allocation is not supported without
>> IOMMU, falling back to contiguous buffer
>>
>> Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
>>
>> I will start bisect and try to isolate the problem. I suspect this is
>> related to dts
>> changes perhaps? I used to this problem a while back and it has been
>> fixed.
>
>
> This warning has been added intentionally, see following discussions:
> https://patchwork.kernel.org/patch/10034919/
> https://patchwork.kernel.org/patch/10070475/
>
> This means that your test apps should be updated or you should enable Exynos
> IOMMU support in your config. Maybe it is a good time to finally enable it
> in exynos_defconfig.
>

Has the issue that the boot-loader keeps the display controller
enabled and scanning pages on the Exynos Chromebooks resolved?

I think that's that preventing to enable it by default in
exynos_defconfig since it caused boot failures when enabled on these
machines. I don't follow exynos development too closely nowadays so
maybe there's a fix in place now.

> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland

Best regards,
Javier