From: shuahkh@osg.samsung.com (Shuah Khan)
To: linux-arm-kernel@lists.infradead.org
Subject: mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
Date: Mon, 11 Dec 2017 16:25:26 -0700 [thread overview]
Message-ID: <2df0fc74-8b79-5cca-7a8a-9e005b44d8d8@osg.samsung.com> (raw)
In-Reply-To: <20171211230213.GB1959@n2100.armlinux.org.uk>
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.
thanks,
-- Shuah
next prev parent reply other threads:[~2017-12-11 23:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <680389204.71.1512980755810.JavaMail.jenkins@ip-172-30-0-246>
[not found] ` <51e6d7fb-ac9e-a59f-ea63-ad06219b429d@collabora.com>
2017-12-11 17:05 ` mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging Daniel Vetter
2017-12-11 22:28 ` Javier Martinez Canillas
2017-12-11 22:54 ` Javier Martinez Canillas
2017-12-11 22:58 ` Russell King - ARM Linux
2017-12-11 23:02 ` Russell King - ARM Linux
2017-12-11 23:25 ` Shuah Khan [this message]
2017-12-12 7:54 ` Marek Szyprowski
2017-12-12 8:00 ` Javier Martinez Canillas
2017-12-12 8:47 ` Marek Szyprowski
2017-12-12 10:10 ` Krzysztof Kozlowski
2017-12-12 14:47 ` Shuah Khan
2017-12-12 18:26 ` Shuah Khan
2017-12-12 18:58 ` Javier Martinez Canillas
2017-12-12 11:38 ` Marek Szyprowski
2017-12-12 14:39 ` Shuah Khan
2017-12-12 18:14 ` Daniel Vetter
2017-12-13 9:02 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2df0fc74-8b79-5cca-7a8a-9e005b44d8d8@osg.samsung.com \
--to=shuahkh@osg.samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox